Keeping SELinux on (was Attention: Proprietary video driver users (ATI, Nvidia, etc.))
benjy.grogan at gmail.com
Fri Feb 24 13:07:03 UTC 2006
On 2/24/06, Ivan Gyurdiev <ivg2 at cornell.edu> wrote:
> >> That was my understanding of SELinux. You could run a crazy program
> >> that has root privileges, is hackable, has no SELinux policy, and all
> >> that effort was for nigh.
> It goes more like:
> - "I have a crazy program that has root privileges, is hackable, has no
> SELinux policy"
> - "I'll write a selinux policy for it"
> - "Now the program's still hackable, but at least it doesn't break
> anything else when it gets get hacked"
> I'm not sure what you expect to happen - policy should write itself?
> Programs without a policy run in a high privilege domain, because we
> still want those programs to work, even though nobody has written a
> policy for them. It's easy to restrict those programs to run in a low
> privilege domain. Then they wouldn't work at all, and you'd only be able
> to run confined programs - I doubt this is what you want.
> Note that strict policy confines a lot more things that targeted does -
> it's meant to be used in a locked-down environment.
> (Unfortunately it seems broken at the moment, but I'm sure most of it
> will be fixed by FC5).
I'm in favor of SELinux. I've heard that when writing these policies the
developers have actually improved the applications themselves. They
realized that an application didn't really need this or that permission and
so they adjusted the code and wrote an even better policy. SELinux seems to
have some use in debugging software.
If people are afraid of SELinux I think what's need is more education on
it. more "layman" articles getting across a few of the "ideas" behind
I think some hello world examples of writing an SELinux policy for a simple
daemon would be good.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel