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.
Attachment:
signature.asc
Description: This is a digitally signed message part
