Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Oct 2006 16:50:09 +0800
From:      "Zhang Ye" <yeahchang@vip.sina.com>
To:        "'Borja Marcos'" <BORJAMAR@SARENET.ES>
Cc:        freebsd-security@freebsd.org
Subject:   Re: Proposal: MAC_BIBA and real-world usage
Message-ID:  <000601c6ef6d$c50dfda0$0b00a8c0@zhangamuufcjz4>
In-Reply-To: <588E5B66-F621-4639-9F56-A65A2DFC471A@SARENET.ES>

next in thread | previous in thread | raw e-mail | index | archive | help
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-----
Hello,

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

In short, it's an excellent model, and can be used succesfully if =20
applications are aware of its existance, but I find it incompatible =20
with the real-world needs in Unix, and, worse, when none of the =20
applications we are using are prepared to take advantage of it. So it =20
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 =20
Apache should run as an unprivileged user. The mac_bsdextended policy =20
can implement an additional layer of security. In my case, hosting =20
users are given uids belonging to an interval, and there is a ugidfw =20
rule that states that subjects with an uid withing that range can =20
only access objects belonging to the same user in case their uid is =20
within the interval as well. I didn't use MAC compartments because =20
there is a limit on the number of compartments.

Users are allowed to run CGIs and PHP scripts, and PHP is ran as CGI, =20
so that each process will have the uid of its owner. Launching PHP as =20
a CGI hurts performance, but this is a server for relatively low-=20
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 =20
Apache should not be able to modify any files in the system, except =20
at designated directories in case PHP scripts or CGI programs need to =20
write something to the disk. This is naturally done with MAC_BIBA. We =20
launch Apache with biba/low(low-low) credentials.

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

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

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

Of course it weakens the BIBA model, but used wisely it could really =20
help. Instead of a global sysctl flag, which would disable one of the =20
great BIBA features, it could be done selectively for some processes =20
(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 =20
of being limited to objects with an integrity level equal to N.

What do you think? Any ideas?






Borja.


_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to =
"freebsd-security-unsubscribe@freebsd.org"





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000601c6ef6d$c50dfda0$0b00a8c0>