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
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?
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"