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



## ta0kira (Mar 26, 2013)

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 (Mar 26, 2013)

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


----------



## ta0kira (Mar 26, 2013)

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


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


----------



## ta0kira (Mar 26, 2013)

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.


----------



## ta0kira (Apr 10, 2013)

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


----------



## SirDice (Apr 10, 2013)

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.


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.


----------



## ta0kira (Apr 11, 2013)

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.


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.


----------

