setfsmac and LOMAC aux grades - inconsistent behaviour

priit at cc.ttu.ee priit at cc.ttu.ee
Sun Apr 28 12:26:51 UTC 2013


A bit of a background: I've been experimenting with LOMAC labels on a 
9.1-RELEASE test system. To get the dynamic IP assigned to the machine, I 
tried following recipe: set the label for /sbin/dhclient to 
lomac/high[low]. This gets the job done, but there were a few problems: 
first of all, this label does not seem to persist after a reboot - I have 
not yet found a reasonable explanation for this. However, that would not 
be an issue, as it seems a LOMAC/MLS setup would need a script at boot 
time to update the labels anyway - the /dev filesystem needs them too.

When running a script to set the labels from /etc/rc.d I ran into the 
following problem. Here's the relevant part of the script:

 	check_startmsgs && echo -n "Setting MAC policy: "
 	getpmac
 	id
 	ls -lZ /sbin/dhclient
 	/usr/sbin/setpmac lomac/equal,mls/equal \
 		/usr/sbin/setfsmac -v -ef /usr/home/test/mac.policy /
 	ls -lZ /sbin/dhclient
 	setfmac lomac/high\[low\] /sbin/dhclient
 	ls -lZ /sbin/dhclient
 	check_startmsgs && echo '.'

It produces the following output on boot:

Setting MAC policy: lomac/high(low-high),mls/low(low-high)
uid=0(root) gid=0(wheel) groups=0(wheel)
-r-xr-xr-x  1 root  wheel  lomac/high,mls/low 93616 Dec  4 11:33 
/sbin/dhclient
setfsmac: /usr/home/test/mac.policy: read 1 specifications
/sbin/dhclient matched by (^/sbin/dhclient$,lomac/high[low])
-r-xr-xr-x  1 root  wheel  lomac/high,mls/low 93616 Dec  4 11:33 
/sbin/dhclient
-r-xr-xr-x  1 root  wheel  lomac/high[low],mls/low 93616 Dec  4 11:33 
/sbin/dhcl
ient
.

As you can see, the setfsmac command fails to set the aux grade (but 
doesn't give an error), the following setfmac command succeeds.

The file mac.policy contains just this:

/sbin/dhclient                  lomac/high[low]

Normally, one would suspect that something is wrong with the syntax in 
this file. After all, setfmac and setfsmac are essentially the same 
program. However, when logged in as root, running the same script results 
in setting the label correctly by the setfsmac command. I can only 
conclude, that in the case described above, mac_set_file(), as called by 
setfsmac does not return an error but does not set the label either. There 
does not seem to be a scenario where the call would fail and setfsmac 
would be silent about it.

I've also experimented with setting other labels this way and that 
appeared to work normally (skipping the detailed results to keep things 
brief). The only case of failure I found was setting a LOMAC aux grade, by 
setfsmac, from a boot-time script.

To avoid any misunderstanding, the issue here is the ability to set the 
aux grade on the binary. Getting the IP configured was just the way I 
stumbled into this and can of course be handled in other ways. Also, it is 
probably obvious from the above script listing, but the files sit on / 
filesystem that has multilabel set. lomac and mls modules are loaded.

Priit.


More information about the freebsd-security mailing list