SELinux blocking Gizmo on FC5

[Craig White]

On Sun, 2006-04-02 at 11:17 +0200, A.J. Bonnema wrote:
> Craig White wrote:

> > 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?
----
probably common sense
----
> >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.
----
Considering that SELinux is a kernel level security device and switching
a context or a policy that has blocked activities from someone who has
already breached a service - say http via an old version of phpbb, my
answer would have to be no, you just allowed them to wreak havoc. Thus I
couldn't agree with the extensions you make.
----
> 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.
----
again - SELinux is a last line of defense. The security breaches have
already occurred in the case of a 'cracker' by the time SELinux has
recorded 'blocks' and SELinux has 'hopefully' severely restricted what
he is capable of doing.
----
> 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? 
----
No - it is an additional layer of security.

Craig