| |||||||||||||
Why we should careWhy we should carePosted Aug 17, 2005 19:33 UTC (Wed) by cdmiller (subscriber, #2813)In reply to: Why we should care by kokopelli Parent article: An overview of multilevel security
Show an example that falls outside of what can be done with the existing permission system, then we, (I at least), will care more.
(Log in to post comments)
Why we should care Posted Aug 17, 2005 20:35 UTC (Wed) by jmshh (guest, #8257) [Link] You are right that the result of MLS can be achieved mostly by replacingthose labels with groups. The problem is: this will result in lots of groups to manage, therefore lots of possibilities for mismanagement. MLS reduces complexity from m×n down to n+m for combinations of confidentiality and subjects.
Why we should care Posted Aug 18, 2005 3:07 UTC (Thu) by flewellyn (subscriber, #5047) [Link] The existing permissions system is discretionary, i.e., the permissions are set at the discretion ofthe file owner. If a sensitive file is owned by root, this may not (always) be such a big deal; but if a sensitive file is owned by a particular user ("daemon" users included!), then nothing prohibits a process running as that user from changing the permissions.
SELinux's mandatory controls override this. Something labeled as "secret", for instance, could be
Why we should care Posted Aug 18, 2005 7:54 UTC (Thu) by jmshh (guest, #8257) [Link] Mandatory access control is something else. It aims at the same goal:reducing errors in the security configuration. Best way of working is to use them both.
Why we should care Posted Aug 18, 2005 11:49 UTC (Thu) by druiloor (guest, #26069) [Link] As i see it, most of this MAC stuff could (theoretically) be done with a combination of: Unix groups, POSIX filesystem ACLs, and extended artibutes (administated with like CAP_LINUX_IMMUTABLE privs.)
However that might be major pain, and not al all easy to get right ...
What i found to be a good read, discussing security inc MAC, MLS, et al:
Why we should care Posted Aug 18, 2005 8:00 UTC (Thu) by janfrode (subscriber, #244) [Link]
Readable by everybody:
/etc/passwd
Not readable by any processes started by users logged in via eth0:
/etc/ssh/ssh_host_rsa_key
sshd started from /etc/rc*.d/ belongs to a different domain than prosesses initiated from eth0, so sshd can read this file.
Why we should care Posted Aug 20, 2005 4:27 UTC (Sat) by josh_stern (guest, #4868) [Link] One good example would be a system that assigns different sensitivity levels to UserX when logged in an an on-site console vs. logged in remotely. At first glance, you think, "why would putting up with that PITA be a good thing?" It's mainly a good thing on systems where allowing remote login at all might otherwise be considered too risky. On such a system, this extra removal of priviledge for the remote login is what enables it at all.
|
|||||||||||||