RFC: Requirements for MAC policies and implementation

[Robert Watson]

As the initial fine-grained privilege/capability support infrastructure
for FreeBSD is nearing completion, I figured it was time to raise some
design requirement questions concerning mandatory access control.  Ilmar
has already made some initial implementation efforts in this area, as he
did with capabilities before I picked up that project, so I thought I'd
raise them sooner rather than later :-). 

Mandatory access control means a lot of things to different people.  In my
mind, there are a few common MAC models that are appealing in the context
of a first revision TrustedBSD distribution.  These include traditional
Multi-Level Security (Bell-LaPadula, et al), integrity models (Biba, et
al), as well as strong partitioning schemes.  Some potential consumers of
TrustedBSD have expressed strong interests in each of these models, so I
think it's fair to take them all for granted as requirements.  There are
many worked examples of these models in other trusted operating systems,
but I think that the TrustedBSD implementation has somewhat differing
requirements in a number of ways. 

- Multi-Level Security Model (MLS)
	- MLS is fairly cut-and-dry -- I'd assume support for
	  static labels, some fixed finite bound on the number of
	  sensitivity levels, and support for non-hierarchal categories. 
	  All trusted operating systems support this model, albeit
	  some in a more general manner than others.

- Biba Integrity Model
	- A static label Biba integrity policy, aimed at both
	  protecting the TCB, and to be used to protect the user
	  application environment.  Both SGI and Argus Systems
	  have worked examples of this, and its usefulness has been
	  widely demonstrated.  Presumably, as with MLS, both
	  hierarchal integrity levels and non-heirarchal divisions
	  would be useful.

- Strong Non-Intersecting Partition Model
	- The jail() mechanism in FreeBSD 4.x-STABLE has proven quite
	  popular, allowing the light-weight partitioning of FreeBSD
	  environments in a scalable manner.  This can be reproduced
	  using a combination of MLS + Biba non-hierarchal categories,
	  but as these categories tend to be based on set operations
	  and lists, there is limited scalability.  Improved abstraction
	  of the jail() mechanism, optimized for large numbers of
	  non-intersecting compartments, would make a lot of sense
	  and be relatively straight-forward to implement.  A simple
	  optimization would be to use a unique partition index,
	  with special cases to reflect the current day "not in a jail"
	  case.

- Labeling Issues
	- Objects intended to be protected by mandatory access schemes
	  must be labeled.  Clear this includes processes, files and
	  other file system objects.  However, how does labeling apply
	  to sockets, network interface abstractions such as packets,
	  ports, addresses, interfaces, routing?  What about multi-level
	  packet tagging schemes?

	- Desirable functionality might include: trusted vs. untrusted
	  network interfaces (must log in from the trusted network to
	  acquire high secrecy), integrity labeling based on the protocol
	  used (SSH required for high integrity access), partitioning
	  based on address, correct local handling of IPC in a consistent
	  manner, capable of supporting X Windows and CMW configurations. 
	  Also, traditional multi-level IP protocol security options
	  may be desirable to allow interoperability in networked MLS
	  environments.

- Access Control Points
	- Access control points for mandatory policies would certainly
	  include all existing discretionary access control points (file
	  name lookup and open operations, socket creation, inter-process
	  control such as signaling and debugging), but what other
	  points may now require access control or revocation?

	- Floating label schemes would require access control and
	  revocation at the granularity of individual reads/writes
	  rather than the DAC cached credential model for file and
	  socket access.  Revocation even in non-floating schemes might
	  demand blocking access to previously accessible services
	  such as file descriptors and sockets, based on the requirements
	  of the scheme.  Similarly, shared memory resources might
	  fall under revocation environments, something that the VM
	  system has not been designed for.

I'd welcome discussion, suggestions, questions, et al, relating to any of
these points, including specifically the choice of models to implement,
requirements for those models (labeling, access control points), etc. 
With improved discretionary access control and management of privilege, I
think we're on much further ground when it comes to successfully
understanding the implementation issues than six months ago.  I certainly
don't expect that this list of implementation possibilities is the last
word on the topic. :-)

There are a number of resources that participants might find useful for
framing the discussion, including technial reports and documentation from
Argus Systems (http://www.argussystems.com/pitbull/,
http://www.argusrevolution.com/), and SGI
(http://oss.sgi.com/projects/ob1/doc/).  Keeping standard CC protection
profiles in mind is also good, so
http://www.radium.ncsc.mil/tpep/library/protection_profiles/index.html is
also a useful reference. 

For reference with regards to long term development plans, this MAC
implementation would be prior to the implementation of a generalized
labeling and access control scheme such as Poligraph, but would be a
useful step towards the implementation of such a system, providing a
stronger understanding of requirements for the implementation of these
common MAC schemes. 

  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