# A few questions about mac_mls and mac_biba



## jirka (Jan 23, 2013)

Hello,

I'm new to FreeBSD (I've been currently experimenting with FreeBSD 9.0-RELEASE) and I've been playing with mac_mls and mac_biba a bit. I have some questions about using these MAC modules, to which I haven't found any answers:

1. I wanted to set up a few login classes with a range of compartments, but it never worked. Say, for example, I'd like to have a login class with default MAC label set to mls/5, with possible ranges from 2 to 10 and with possible compartments from 1+2+3 to 1+2+3+4. This is what I added to /etc/login.conf:

```
mlsclass:\
     :label=mls/5(2:1+2+3-10:1+2+3+4):
```
but it doesn't work. I also tried to escape the brackets and/or the colons in the label definition with a backslash, but with the same result. After login, the user with the security class mlsclass doesn't have a label mls/5(2:1+2+3-10:1+2+3+4) as I would expect, but mls/5(low-high) instead. Of course I run `# cap_mkdb /etc/login.conf` after a change of the class definition. Is there anything I do wrong or what I've understood wrong?

2. The compartments can only be determined by a number (1-256), or there is a way to use a text label for them instead of numbers?

3. Is there a simpler way to manage the labels for different login classes than manually editing /etc/login.conf?

4. One practical use of the aforementioned MAC modules is probably setting mandatory rules which files/directories can be accessed by the users in different login classes. What could be other uses for those modules in practice?  I thought of some, but then I told myself there would probably be better solutions than those modules (e. g. using mac_biba for a webserver within an insecure class running at biba/low with the served files labeled biba/low, but there would be other ways to secure the system from possible webserver vulnerabilities, such as jails?).

Thank you very much in advance for your answers!


----------



## jirka (Feb 3, 2013)

Nobody has any idea about my questions? :-( At least I'd be very glad to find answers for questions 1 and 4...


----------



## bryn1u (Feb 3, 2013)

*Little help.*

I'm looking for more tutorials about MAC but there is nothing! There is such less documentation about MAC that *I'm* so angry. This is the one of strongest site of freebsd FreeBSD and so less information about. I have been looking by all the time and found nothing. I have found only something from 2004 maybe it can help *yo*u.



> ```
> CONTENTS
> =====================================
> 
> ...



More you will see under link: -> http://lists.freebsd.org/pipermail/trustedbsd-discuss/2004-April/000547.html

I can't paste more bec*a*use of restrictions. Let me know if it helps you.


----------



## jirka (Feb 4, 2013)

Hi bryn1u,

thank you for your effort to help me. I know the text you posted, and I strongly agree with you that there's a serious lack in documentation and howtos relating to the MAC framework in TrustedBSD. That's why I asked the questions above . I hope I will be able to answer them at least partially (the sooner the better).


----------



## ta0kira (Mar 13, 2013)

I think the default compartments (corresponding to "5") need to at least contain the low end ("1+2+3") but no more than the high end ("1+2+3+4"). In other words, with "_a:A(b:B-c:C)_" you need _b<=a<=c_ and _B subset A subset C_. For example, you could try "mls/5*:1+2+3*(2:1+2+3-10:1+2+3+4)".
Kevin Barry


----------



## jirka (Apr 2, 2013)

Hi Kevin,

You're right with the dominance of the A, B, C subsets, but I'm still afraid it doesn't work as expected. In the example I posted earlier, I made the mistake that the default security level wasn't higher or equal to the low security level. So I tried to set MLS label for the login class of my user to mls/1:1(1:1-2:1+2), which should be OK AFAIK. But still it doesn't work as it should:


```
$ getpmac
mls/1(low-high)
```

It seems like I don't get something important, or the classes are somewhat broken in the MAC framework. I also noticed one think that kind of breaks the information flow in MLS - a user can manipulate the security label within the range of his security levels in both ways - he can upgrade the label to a higher level (which in fact could be OK), but he also can downgrade it, which could cause information leak. Is there any way to disable it, or it's a bug, or it's just a feature of the MLS implementation in the FreeBSD Mac framework?


----------



## ta0kira (Apr 2, 2013)

What method are you using to switch to that user, e.g. console login, ssh, su, sudo, etc.? The first two set the MAC label for the user, but the last two don't by default.

Kevin Barry


----------



## jirka (Apr 2, 2013)

In this case it was just a console login. Btw, what's your opinion on the upgrade/downgrade possibility of the files' level within the user's security levels range?


----------



## ta0kira (Apr 2, 2013)

jirka said:
			
		

> Btw, what's your opinion on the upgrade/downgrade possibility of the files' level within the user's security levels range?


Without this you'd never be able to use multilabel because you can't create a file in a directory that has a different MAC label. The MAC label of the directory effectively places a bound on the MAC labels of the contained files (notwithstanding the almighty process labels mls/equal and biba/equal.) For mac_mls this is a lower boundary and for mac_biba this is an upper boundary. Take the following two examples.

My home directory is mls/low and I can't `$ setpmac mls/1 touch test`. I can, however, `$ touch test && setpmac mls/1 setfmac mls/1 test`. In this case, I can create "test" because I'm in mls/low and so is the directory, and I can change the MAC label because I can go to mls/1 and still access the directory.
On the other hand, if I was in an mls/1 directory operating at mls/1(low-1) I _couldn't_ do `$ touch test && setpmac mls/low setfmac mls/low test` because as soon as I go to mls/low I can no longer access the current directory. You could easily write a program in C that buffers from an mls/1 file, changes to mls/low, and writes to an mls/low file, which would circumvent any attempt to prevent downgrading files, except that the file being written to would have to be in a location both readable and writable by that process (which can further be restricted by mac_biba.)
In this case it's a compromise to let users change file labels, because otherwise you'd need an all-powerful mls/equal user to go around and maintain all of the places where a file's label needs to differ from that of the containing directory. I think the idea is that your level of trust of the user dictates his/her label range. If you don't trust a user to not "inappropriately declassify" files then that person should not be able to access the higher and lower levels within the same process. Compartmentalization is inherently inconvenient, but small compromises need to exist so that larger compromises don't become common practice. It's the same philosophy that inspires tools like sudo, without which you'd have to decide between handing out the root password and tightly controlling all sysadmin yourself. If you absolutely cannot tolerate a particular file being downgraded then you need to prevent all processes from having access to both level "x" and "x-1" at the same time.





			
				jirka said:
			
		

> So I tried to set MLS label for the login class of my user to mls/1:1(1:1-2:1+2), which should be OK AFAIK.


You should try this without the compartments to see if you get mls/1(1-2) when you log in.


On a related topic, I think a very powerful use of mac_mls and mac_biba is to hide _processes_. For example, you can run a process at mls/high and set the MAC label for all login classes to something lower, so even someone with root access won't be able to detect or terminate that process. This, of course, requires that you limit the MAC label of sshd; otherwise, someone could just edit /etc/login.conf and log in again.

Kevin Barry


----------



## jirka (Apr 4, 2013)

ta0kira said:
			
		

> Without this you'd never be able to use multilabel


To be honest, I don't know what exactly the _multilabel_ option means - does that mean that I can have an object (file, directory, ...) with a range of security levels, or multiple labels per file (for example, mls/1 and biba/equal), or even something else?

I agree that in most cases there's a tradeoff between security and usability... But still, not having known that mac_mls works this way, I would expect for example that a user would be able to create a new file on any level in his range, or maybe upgrade a level of an existing file if he's the owner, but that he won't be able to downgrade it (or at least that there would be an option to force this behavior). Yes, I know that the theory and real use are two different things.



> You should try this without the compartments to see if you get mls/1(1-2) when you log in.



When I try to set up a security level range without compartments, I get exactly what I expected. For example, I set mls/1(1-2) and get

```
$ getpmac
mls/1(1-2)
```
but when I add compartments, it looks like this (for mls/1:1(1:1-2:1)):

```
$ getpmac
mls/1(low-high)
```
, just in the same way I mentioned earlier.


----------



## ta0kira (Apr 6, 2013)

jirka said:
			
		

> To be honest, I don't know what exactly the _multilabel_ option means - does that mean that I can have an object (file, directory, ...) with a range of security levels, or multiple labels per file (for example, mls/1 and biba/equal), or even something else?


It means that every file has its own respective MAC label, vs. every file on the filesystem sharing a global MAC label.





			
				jirka said:
			
		

> I agree that in most cases there's a tradeoff between security and usability... But still, not having known that mac_mls works this way, I would expect for example that a user would be able to create a new file on any level in his range, or maybe upgrade a level of an existing file if he's the owner, but that he won't be able to downgrade it (or at least that there would be an option to force this behavior). Yes, I know that the theory and real use are two different things.


In many cases sensitive information becomes less sensitive over time. It's also more costly to protect sensitive data, so organizations often downgrade sensitivity whenever possible. This obviously isn't universal, since some information is sensitive for a very long time (e.g. medical and legal information.)





			
				jirka said:
			
		

> When I try to set up a security level range without compartments, I get exactly what I expected. For example, I set mls/1(1-2) and get
> 
> ```
> $ getpmac
> ...


I think the problem is that ":" is a delimiter for login.conf, so cap_mkdb stops parsing the label with mls/1. You should try escaping the ":" with "\", i.e. mls/1\:1(1\:1-2\:1).

Kevin Barry


----------



## jirka (Apr 11, 2013)

ta0kira said:
			
		

> It means that every file has its own respective MAC label, vs. every file on the filesystem sharing a global MAC label.


Thank you, now it's clear to me.



> You should try escaping the ":" with "\", i.e. mls/1\:1(1\:1-2\:1).


Unfortunately this doesn't work either. I also tried to put the whole label between single or double quotes, without success.


----------



## ta0kira (Apr 11, 2013)

Sorry, just found this in the login.conf manpage:
	
	



```
Note that since a colon (`:') is used to separate capability entries, a
     `[B][U]\c[/U][/B]' escape sequence must be used to embed a literal colon in the value
     or name of a capability.
```
Kevin Barry


----------



## jirka (Apr 11, 2013)

Sweet, now it works fine . Thank you very much for your effort.


----------

