Do I need to set a character device to mls/high if it has mls/high files on it?

T

ta0kira

I have a few UFS2 filesystems with multilabel enabled, and some areas of each are designated mls/high. Do I need to set the MAC labels of the corresponding character devices to mls/high to adequately prevent read access to those areas? I know I can raise kern.securelevel to protect them from writing, but the point of mac_mls is to prevent reading. The kernel runs at mls/equal, but I'm wondering if it will deny access to mls/low files from mls/low processes. Thanks!

Kevin Barry
 
SirDice said:
I don't know much about MAC but FreeBSD doesn't have block devices.

http://www.freebsd.org/doc/en/books/arch-handbook/driverbasics-block.html
Click to expand...
Thanks. Please see my revised post with "character" in place of "block", meant to mean e.g. /dev/ada0p2, which has a UFS2 filesystem containing mls/high files. Maybe I should say "disk" instead, since that's what security(7) refers to them as. Regardless of what the device type is, I'd like to know if I need to take extra precautions to keep the mls/high files from being read.

Also, if I lock down the file corresponding to the disk (e.g. # setfmac mls/high /dev/ada0p2,) could someone logged in as root just mknod another one? If so, can mac_mls actually be used to completely confine a root process? For example, I don't run sshd at mls/high so that even with sudo, etc. one can't access the mls/high areas, but if someone can just $ sudo mknod ... a copy of the device file, is there really any way to prevent those files from being read remotely?

Thanks!

Kevin Barry
 
Just an update. I tried setting the devices to mls/high and nothing bad happened. I also tried to replicate the device with mknod, both in /dev and elsewhere. It wouldn't work in /dev, nor anywhere on the root partition (UFS2.) It did work on a ZFS partition, but I couldn't read anything from the device. That's a good sign, but not really a guarantee.

edit: To be clear, the answer to my question is "yes". With the default mls/low label on most of the devices in /dev, I'm able to dd the disk as root running at mls/low. It's therefore not out of the question for a userland program run as root to parse the filesystem structure and find the files that the kernel would otherwise block access to.
 
Another issue that requires consideration is that every new mount of devfs will have the default device labels; therefore, one merely has to mount devfs again to circumvent the mls/high label. Of course, not just anyone should have root access, but for MLS to be effective without prohibiting root privileges then you need to use it in conjunction with a jail so that you can restrict devfs mounts and fix the ruleset.

Kevin Barry
 
ta0kira said:
for MLS to be effective without prohibiting root privileges then you need to use it in conjunction with a jail so that you can restrict devfs mounts and fix the ruleset.
Click to expand...
It may be nice if you could set the label with devfs.conf(5) or devfs.rules(5). Although I think the first would be more appropriate, it already has a perm keyword to set permissions. Maybe an fmac keyword to set the MAC label.
 
SirDice said:
It may be nice if you could set the label with devfs.conf(5) or devfs.rules(5). Although I think the first would be more appropriate, it already has a perm keyword to set permissions. Maybe an fmac keyword to set the MAC label.
Click to expand...
I was thinking that, also. You'd also need to protect whatever userland config files contained those settings, though, either with MLS or with schg and securelevel > 0.
 
You must log in or register to reply here.
Back
Top