Weekly Edition
Return to the Security page
| |||||||||||||
An overview of multilevel security
One of the many features added to the 2.6.12 kernel is multilevel security support for SELinux. The only problem is that few people actually understand what MLS is. James Morris has posted a multilevel security overview which makes a good starting point. "The reason why we have categories as well as sensitivities is so that sensitivities can be further compartmented on a need to know basis. For example, while a user may be cleared to Secret, they may not need to know anything about project WarpDrive (which could be the name of a category)."
(Log in to post comments)
Why we should care Posted Aug 17, 2005 16:50 UTC (Wed) by kokopelli (guest, #11341) [Link] My 'to do' list has included writing an article on MLS and why the typical Linux sysadmin (and many users) should care.
The standard classification labels applied to our systems:
sensitive: /etc/passwd
secret: /etc/shadow
top secret: /etc/ssh/ssh_host_rsa_key
The rough idea is that anything marked "sensitive" should be accessible to anyone on the system, but you don't want it freely available to outsiders.
Anything marked "secret" should only be accessible to authorized users and processes. The files should be backed up. The damage caused by disclosure is relatively modest, is contained to this system, and the contents can be changed with low impact on others. (I don't care if you change your password.)
Anything marked "top secret" should only be accessible to authorized users and processes. The files should not be backed up. (More precisely, they should not be archived unless there is extremely tight control of all media.) Disclosure will have a significant impact on others, cannot be contained on this system, or will have a high impact on others. (My security protocols will fail if you change your system's SSH key.)
In practice we would probably want to use our own labels but the idea would be the same.
A similar point can be made on the contents of our files. Most of what people work on is sensitive, the HR department files are secret. Ditto the files at your doctor's office. On your home system you could flag files 'adult' and block access by the kids.
Why we should care Posted Aug 17, 2005 17:41 UTC (Wed) by just_call_me_fred (guest, #31886) [Link] That was very helpful, thank you.
Why we should care Posted Aug 17, 2005 19:33 UTC (Wed) by cdmiller (subscriber, #2813) [Link] Show an example that falls outside of what can be done with the existing permission system, then we, (I at least), will care more.
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.
Why we should care Posted Aug 17, 2005 21:14 UTC (Wed) by tzafrir (subscriber, #11501) [Link] I hardly see too many hirarchial levels here. Trying to abstract it as multi-level doesn't seem to help much. Unix already has a special super-user and some special cases for "guests".
I also fail to see why the ssh key is more sensetive: the ssh daemon has to be able to read it. Thus it is hard to imagine a system where the super-user (that originally executed the sshd) can't read it.
The implementation of SELinux has created a complex set of rules in parallel of the filesystem. Not a pretty sight. Not very managable.
Why we should care Posted Aug 17, 2005 22:10 UTC (Wed) by smoogen (subscriber, #97) [Link] I think that Selinux is probably soemthing that a home user really cares about.. the places where it is important are more corporate/enterprise systems. The bank wants the person who does package updates not have access to the credit numbers of customers. The hr people dont want the social security data to be available to people who are not priveledged to it. And while encryption might be used to manage the problem.. it does not seem to the whole solution from what I can get out Schneir's books.
In the case of ssh and sensitivity.. I would say that the sshd daemon would have the priveledge of reading that file, but not have the priveledge of reading your /home/snsr/bank_balance.txt file (in the slight case that a root level exploit was found in ssh)
Why we should care Posted Aug 18, 2005 20:47 UTC (Thu) by tzafrir (subscriber, #11501) [Link] Impossible, as sshd needs to launch the shell account of that user. sshd also needs to read a number of files from the user's home directory for some authentication methods.
Sshd already employs priviliges seperation: the part that interacts with unauthenticated remote users (and is thus in the best position to be attacked) runs in in an unpriviliged chrooted jail and connects with the priviliged part through a socket.
Only that unpriviliged part needs to know the server key, I believe.
Another solution: make the ssh private key readable to the group sshd and add sshd to the group sshd. Sshd then does not need to be root to read that file. and we're still using standard unix permissions.
Fedora is poorly documented. Posted Aug 18, 2005 15:45 UTC (Thu) by Junior_Samples (guest, #26737) [Link] While SELinux has great potential, it seems that it offers very little to the ordinary user. The default configuration of Fedora is geared toward an enterprise server, not a desktop user. As it stands, SELinux on Fedora doesn't do much to protect the average workstation/desktop user from hax0rs.Poor documentation and lack of communications only make matters worse. During a recent upgrade, Fedora added a audit-libs as a dependency for SELinux. So yum happily installed audit-libs. Now cryptic audit messages are constantly spewed onto to my console. Not a warning or a peep from Fedora. Just a rude unwanted "Easter Egg" as a side effect of an upgrade. So even though my plate is alreay piled high, I must find a few hours of free time to learn and configure auditing. I didn't ask for this. It was dumped on me without permission. As it stands, the only folks getting much use out of SELinux are those who have turned SELinux into a hobby, much like those devoted to Gimp and other time sinks. The learning curve for SELinux is steep, and in its default configuration does very little to squelch day-zero vulnerabilities. Why is there no comprehensive user's guide to SELinux provided with the Linux documentation? Presumably anyone deploying SELinux in an enterprise situation would need such a document. The O'Reilly book on SELinux is only so-so, not to mention out of date with the current state of SELinux. What is needed is a good user's guide with examples. And it should be provided with SELinux as part of the standard install. It is foolish to think that someone can effectively administer a complicated security system based on glancing at a couple of worthless man pages or reading the source code. Poor documentation continues to be Linux's most glaring weakness.
Fedora is poorly documented. Posted Aug 20, 2005 12:42 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] The current targeted policy in Fedora Core 4 covers 91 deamons many of which has added security to desktop users also.
The release notes provides a list of these
http://fedora.redhat.com/docs/release-notes/fc4/#sn-overview
Fedora Core 5 is expected to take this even further with added usability. See the section on security at
http://fedoraproject.org/wiki/FC5Future
Updates are not supposed to add dependencies. However the audit-libs is a feature of the new 2.6 kernels which SELinux takes advantage of. The audit messages being too noisy is a bug which has already been reported. A errata would fix that.
Documentation on SELinux is currently very detailed. Some of them related to Fedora are
http://fedora.redhat.com/docs/selinux-faq-fc2/
http://fedora.redhat.com/docs/selinux-apache-fc3/
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manu...
(RHEL docs mostly apply to Fedora too)
|
|||||||||||||