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
