Why we should care [LWN.net]

Why we should care

Posted Aug 17, 2005 16:50 UTC (Wed) by kokopelli (guest, #11341)
Parent article: An overview of multilevel security

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.

(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 replacing
those 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 of
the 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
set so that only certain users could read or write the file, and even the file's owner cannot change
this. This level of security in addition to traditional discretionary controls is invaluable.

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:
http://www.google.com/search?q=gasserbook

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.