SELinux should be off by default in FC3

Karl MacMillan kmacmillan at tresys.com
Fri Oct 8 15:47:42 UTC 2004


> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list-
> bounces at redhat.com] On Behalf Of Colin Walters
> > Simplifying the config syntax could make SELinux far more usable.  The
> > current syntax requires the admin to think in terms of SELinux
> > mechanics, not in terms of what they want the system to do.  You can't
> > just write "/bin/foo can only perform read operations, and only
> > on /etc/foo.rc,"
> 
> Having something like that in the policy would add more confusion,
> because it would be a huge special case.   The SELinux policy is simple
> in that the essentials only deal with types - there is the same
> conceptual model for files, as well as processes, TCP ports, etc.
> 
> This would also make it much harder to write a tool like apol which can
> analyze a security policy to determine information flow - can my web
> administrator with control over httpd_t access any nurse_t processes or
> any health_record_t files?
> 

Not only can this type of analysis not be done on the existing DAC
mechanism, if it could that answer could change at any time. With SELinux we
can answer questions like this and know that the answer will remain the same
as long as the policy doesn't change. Also, the flow of information in a
system can help you answer many interesting questions beyond the disclosure
of sensitive information. For example, integrity questions like who/what can
write information to the config files for trusted applications.

Karl

Karl MacMillan
Tresys Technology
http://www.tresys.com
(410)290-1411 ext 134

> > you need to write, "/bin/foo is this
> > context, /etc/foo.rc is this context, and the traits between these are
> > this" and so on.  Low-level implementation details are directly exposed.
> 
> It's not "implementation details" - types are fundamental to
> understanding and using MAC, they cannot be hidden.
> 





More information about the fedora-devel-list mailing list