On Thu, 2004-10-07 at 19:11 +0200, Arjan van de Ven wrote: > On Thu, 2004-10-07 at 19:00, Stephen Smalley wrote: > > Or alternatively, customize the policy to fit your needs. That is why > > SELinux is flexible - because no single policy meets everyone's needs. > > while that is true it sure should be possible to have a policy that can > be used by default and doesn't change existing "this works" practice. > Even if that policy allows a bit more than you would want. The standard apache policy tries to capture a "typical" Apache setup. There will always be people doing things outside these bounds; I saw a bug report from someone who had configured Apache to load modules from his user's home directory. We never want SELinux to get to the point where all these weird things people do work out of the box, because then it's equivalent to no protection at all. Apache is an extremely flexible piece of software. One thing I think that's often misunderstood is that SELinux is explicitly designed to be a layer explicitly *separate* from the Unix configuration. This does mean you might have to configure something twice - if you want Apache to bind on some weird port, you will have to do that both in httpd.conf and in the SELinux policy. But the flip side of this, and it's a very important feature I think, is that it allows you to separate the job of administering Apache from the system security policy. For example, with SELinux you can give someone full access to Apache configuration *without* giving them the equivalent of root system access. They can load any modules they want, change the MIME setup, use mod_rewrite, whatever. But they can't use Apache to escalate their privileges beyond what the system security policy allows. You just can't do that with sudo or whatever. One main point of the "The Inevitablity Of Failure" is that a misconfigured daemon is not fundamentally different from a compromised one.
Attachment:
signature.asc
Description: This is a digitally signed message part
