mac-0.5.diff up on www.TrustedBSD.org

[Robert Watson]

I've posted mac-0.5.diff on the TrustedBSD downloads page.  This release
of the MAC code isn't substantially different in terms of functionality,
primarily consisting of a rather extensive CVS merge with recent FreeBSD
developments.  The patch is intended to apply to FreeBSD 5.0-CURRENT as of
about 11:00am EST on Sept 26, 2001.

As with previous patches, this MAC patch introduces basic support for
mandatory access control to FreeBSD.  It labels processes, file system
objects such as files and directories (but not devices), and network IPC
objects. It enforces MAC policies on inter-process operations such as
visbility via system MIBs, debugging, and signalling.  It enforces MAC
policies on process operations on file system objects for explicit
operations, as well as some implicit operations (such as some conditions
of mmap()).  It integrates basic support for MAC labeling into the login
infrastructure, and allows MAC labels to be associated with user login
classes.  The implemented policies are: Biba fixed-label integrity model,
Multi-Level Security, and a custom "partition" scheme.  This patch does
not include recent progress made by Ilmar in the network labeling/access
control space, nor non-hierarchal MAC categories.

Disclaimer: If you run it, this patch will hurt you, I promise.  Don't do
this on a machine you don't want to sacrifice to the good of the cause.

Instructions:

	# begin by shutting down to single-user mode
	cd /usr/src
	fetch http://www.TrustedBSD.org/downloads/mac-0.5.diff
	mkdir -p usr.sbin/getpmac usr.sbin/setpmac
	mkdir -p usr.sbin/getfmac usr.sbin/setfmac
	patch < mac-0.5.diff
	make buildworld
	make buildkernel KERNCONF=MAC
	make installkernel KERNCONF=MAC
	make installworld
	cp etc/login.conf /etc/login.conf
	cap_mkdb /etc/login.conf

For each file system which will have per-file MAC labels, as opposed to
simply one label for all objects on the file system, you'll need to create
a 16-byte $freebsd.mac attribute backing file in the system namespace:

	cd /fsrootofchoice
	mkdir -p .attribute/system
	extattrctl -p . 15 '.attribute/system/$freebsd.mac'

Unless you plan only to run processes as root, you'll want to do this to
at least /, /usr, and /var.  File systems without explicit labeling will
adopt the label of the process that mounts the file system, which in most
cases will be a root-privileged process with high integrity and low
secrecy.

	reboot

By default, on boot, you will find that root runs with high privilege and
low secrecy.  Because capabilities aren't in the base system yet, root
overrides MAC protections.  Normal users are assigned a low-integrity,
low-secrecy MAC label, and as such will have little privilege in the
system.  To make those users more functional, you'll want to relabel some
key directories and files.  Right now, there is no support for
multi-level-directories, so assign a magic "equal" label value to shared
tmp directories (or use TMPDIR frequently):

	setfmac biba/equal,mls/equal,partition/none /tmp /var/tmp \
		/var/tmp/vi.recover /var/mail

This will cause the label of the directory to match that of the process
regardless of the process label.  This is bad from a security perspective,
but gets the system running.  A more conservative approach would use a
per-user TMPDIR for the time-being.  A simple variant symlink
implementation will be in the next release, permitting some basic MLD
supoprt.

To give a non-root user access to their home directory with the default
policy and labeling, use the following:

	setfmac biba/low,mls/low,partition/none `find /home/rwatson`

(setfmac does not currently have a -R parameter, but will get one in the
next iteratin)

Otherwise users will be able to read but not write their own files.

A useful demonstration of the Biba integrity model runs Apache with low
integrity, a user at some medium integrity level, and the fact that Apache
can read but not modify the content it exports.  Penetration of the Apache
server via compromised CGI does not yield a number of privileges it
normally would.  In fact, the malicious process can't even see what other
processes are operating on the system.  Clearly, there are limitations to
this demonstration with the current implementation (and theoretical limits
on information flow in this environment). 

There may be problems with this release (there always are), so expect
patch updates.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message