Proposal: MAC_BIBA and real-world usage

Zhang Ye yeahchang at
Sat Oct 14 01:50:23 PDT 2006

Hello Borja,

I think you may use the "multilabe" with the combination of both Biba and Bell-LaPadula(Multi-Level) access control model to overcome it(just like Lipner's). And it SHOULD have discretionary mechanism in the Bell-LaPadula model but I don't know whether or not in FreeBSD.

Moreover, the Biba(and Bell-LaPadula) is more suitable in the scenario of army. And there are many models, such as "Chinese Wall" model, for the commerce environment. They are more flexible.

Zhang Ye

-----original message-----

Are there many people actually using the MAC subsystem in the real  
world? I have been working to set up a shared hosting webserver and  
I've stumbled against some limitations with the BIBA policy.

In short, it's an excellent model, and can be used succesfully if  
applications are aware of its existance, but I find it incompatible  
with the real-world needs in Unix, and, worse, when none of the  
applications we are using are prepared to take advantage of it. So it  
should be as transparent as possible.

I started the project with some goals:

1) Users are kept isolated. This isn't so obvious, as by design  
Apache should run as an unprivileged user. The mac_bsdextended policy  
can implement an additional layer of security. In my case, hosting  
users are given uids belonging to an interval, and there is a ugidfw  
rule that states that subjects with an uid withing that range can  
only access objects belonging to the same user in case their uid is  
within the interval as well. I didn't use MAC compartments because  
there is a limit on the number of compartments.

Users are allowed to run CGIs and PHP scripts, and PHP is ran as CGI,  
so that each process will have the uid of its owner. Launching PHP as  
a CGI hurts performance, but this is a server for relatively low- 
volume sites, and security is much more important.

2) OS Integrity. Apache is launched with biba/low(low-low) credentials.

3) Defacements should be prevented. At least processes spawned from  
Apache should not be able to modify any files in the system, except  
at designated directories in case PHP scripts or CGI programs need to  
write something to the disk. This is naturally done with MAC_BIBA. We  
launch Apache with biba/low(low-low) credentials.

4) FTP access for site mainteinance. We assign each user an account,  
which will be used to update their files. The ftp accounts have a low  
integrity credential assigned, but anyway higher than biba/low so  
that files uploaded by users are safe from being modified by Apache.

However, this has a problem: Files created/modified from PHP and/or  
CGIs will be labelled biba/low. And the ftp process, with, say, biba/ 
100, will be unable to read them. We could create two user accounts  
per user but it's just too confusing and error prone.

What about adding a discretionary mechanism to MAC_BIBA? It would be  
useful to have the possibilty of implementing half of the BIBA  
protection, preventing high integrity objects from being modified by  
low integrity subjects, but allowing high integrity subjects to read  
low-integrity objects.

Of course it weakens the BIBA model, but used wisely it could really  
help. Instead of a global sysctl flag, which would disable one of the  
great BIBA features, it could be done selectively for some processes  
(in my case, ftp accounts) specifying a negative value.

So, a subject with biba/-N would be:

- unable to modify objects with a higher than N integrity level

- able to read objects with a lower than N integrity level, instead  
of being limited to objects with an integrity level equal to N.

What do you think? Any ideas?


freebsd-security at mailing list
To unsubscribe, send any mail to "freebsd-security-unsubscribe at"

More information about the freebsd-security mailing list