SELinux should be off by default in FC3

[Colin Walters]

On Thu, 2004-10-07 at 13:23 -0400, Sean Middleditch wrote:
> On Thu, 2004-10-07 at 12:56 -0400, Stephen Smalley wrote:
> > On Thu, 2004-10-07 at 12:07, Jeff Spaleta wrote:
> > > I think there is a point here too.. but let me rephrase it by asking a
> > > question.  Is there ever any value in having files in a path NOT be
> > > the correct security context for that path?
> > 
> > Yes, there is value in customizing your file contexts beyond the default
> > settings.
> 
> The point of the original question (as I interpreted it), is there value
> in having mv, rename, and similar operations not update the file's
> security context to the correct one of the new path?  

Yes.  As Stephen said, moving a file doesn't change its DAC permissions,
so it shouldn't change its MAC label either.

> The common operation should have the expected result.  So, the question
> is, shouldn't the desired behavior of the mv, rename, and similar
> operations be to update the context of the file by default?

You might as well argue that moving a file into ~/public_html should
make it automagically readable by Apache, even if the file mode is 600.

> Most people do not complain about MAC due to the fact that it does what
> it does.  Most complaints on SELinux are because it's far too complex to
> get it to do what it does.  Complexity is the bane of security.  Lack of
> education on security is the biggest security problem of them all.
> SELinux adds a lot of complexity and increases the amount of education a
> user/admin needs to operate a secured system.

One certainly needs to learn more, but fundamental advancements like
this will always require learning new things.  That's just life.

> The SELinux configuration syntax makes it vastly too difficult to
> configure things for the common case.  The format makes it possible to
> do just about anything, yes, but when you just know that binary foo only
> needs to do X and Y to files A and B, 

There is a *lot* more than just files that require protection.
Processes, file descriptors, ports, sysv shmem, etc.

> 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?

> 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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20041007/0b70a4a5/attachment.sig>