MAC requirements, status

[Robert Watson]

I've been poking through the SGI TRIX MAC implementation, available
courtesy of SGI's oss.sgi.com site (a great resource :-).  FreeBSD has
slightly different requirements in terms of scalability, as I believe
there are non-traditional applications of MAC mechanisms that could be
used to support facilities such as jail().

My first observation is that the SGI implementation supports both Biba and
MLS models, providing integrity and secrecy protection based in
independent label contents on subjects and objects.

The integrity protection provides protection of the operation system, and
presumably can also be used to protect applications on the system.  This
model is a convenenient, and useful, super-set of the traditional BSD
securelevel model, and I think would have wide application.  The folks at
Argus Systems have already released a white paper on how integrity
protection can provide important support for every-day Internet
applications.  In fact, many people I have spoken to have argued, quite
convincingly, that outside of traditional MLS environments, clean
integrity protection has far more to offer the operating system community
than the secrecy protection of MLS.  However, that's not to entirely
disparage MLS, as there are many environments where it is useful, and SGI
and Argus have demonstrated that they can be combined in a single system
quite well. 

As the project has been progressing, I've been attempting to reduce some
of the adhoc FreeBSD security features, such as Jail and securelevels, to
generalized mechanisms (integrity protection, privileges) with some degree
of success.  Right now, I'm targetting jail(), attempting to reduce its
suser_xxx(..., PRISON_ROOT) stuff down to a more consistent framework,
treating jail restrictions as an inheritted capability mask, which is a
cleaner way to think about it.  The partitioning properties of jail()
match up fairly well with several MAC techniques, and could also be used
with categories under a combination of MLS (protecting data privacy
between partitions) and Biba (protecting data integrity between
partitions).  Alternatively, it might make more sense to retain a
jail-specific partitioning technique, independent of those two more
general schemes.

On the status side, the capabilities implementation is growing closer to
commit-worthy for the base tree.  I'm currently integrating a set of
general authorization improvements for process-to-process calls, improving
access checks generally, and making the merge of capability support
easier.  I'm also improving the ordering of some access checks to better
differentiate calls that succeed on the basis of discretionary access
checks, and use of privilege.

I'll be updating the capability patches on trustedbsd.org in a day or two
based on these improvements, but in the short term if people want to do
code reviews, I have some of the merge-worthy material at
http://www.freebsd.org/~rwatson/p_stuff.diff.  I hope to commit that
within the next day or two, but am currently getting correctness checks: I
want to avoid committing broken access checks to the FreeBSD-CURRENT tree!

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

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