SELinux blocking Gizmo on FC5

[A.J. Bonnema]

Craig White wrote:
> On Sun, 2006-04-02 at 09:31 +0200, A.J. Bonnema wrote:
>   
>> Michael Wiktowy wrote:
>>     
>>> I just fixed my problem with
>>> chcon -t texrel_shlib_t /usr/lib/libsipphoneapi.so.0.78.20060211
>>> I am not exactly sure what that does though.
>>>       
>> Craig,
>>
>> I wonder how many people do these statements without understanding the 
>> implications? How secure would that be?
>> On this line, what we actually need is some kind of easifier / 
>> dumbifier, if you get my meaning. So it is obvious what the implications 
>> are.
>>     
> ----
> I see your point and agree with it except that you can consider...
>
> the target is /usr/lib/libsippphoneapi.so...
>
> so the adjustment is made to one specific file for one specific purpose
> and the whole of selinux remains intact beyond that. That is
> significant.
>
>   
Hmmmm, I agree that this is significant. It is quite improbable for this 
file to be used for anything other than a SIP Phone.
> It does take a moment of consideration if you are adding rules from say
> audit2allow as some of those 'blocks' may have been caused by selinux
> protections emanating from intrusion attempts and adding them either by
> policy or by file context adjustment would simply open the door for
> them, a slight bit of consideration should be all that is necessary to
> evaluate the reason.
>
>   
> Per this situation, he knew that he installed the 'Gizmo' ip phone
> software so it makes sense that this 'block' occurred from the software
> he wants to run so taking the necessary steps to enable it make sense.
>
> In your specific case, it would appear that you are setting up squid in
> both examples that you gave, so adding the file contexts for squid would
> be perfectly logical.
>   
Okee. Let's say this is true and sound. I could add the file contexts.

Where is the boundary / limit? How do I recognize a perfectly legal and logical action and discriminate this from a potential security hole?

>From your answer, I gather: 

1. A modification of the SELinux policy that is limited to just 1 package is not ever a problem.
This would represent a breach in the security for that area only. An exploit could not take over my machine from this kind of error alone.

2. Any modification to the SELInux system itself (like switching off all booleans or disabling SELinux) are worth scruteny by someone SELinux - knowledgable.

In summary, doing as I could do, I can maximally cause a breach in the wall SELinux, but not a security hole, through which the assailant can take over my system.

Now, let's take the opposite stand. 

Suppose I limit my changes of SELinux components to packages only. Would I be able to mortally wound the security system of SELInux? In other words could I create a fatal, exploitable flaw in the security system? 

Guus.

-- 
A.J. Bonnema, Leiden The Netherlands,
user #328198 (Linux Counter http://counter.li.org)