RFC: Requirements for MAC policies and implementation

[Ilmar S. Habibulin]

On Wed, 20 Sep 2000, Robert Watson wrote:

> 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 :-). 
Sorry, but i have no time right now to make it not "initial".

> 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. 
And what about Domain Type Enforcement? I think that it's something
simular to jail. Tim send me some papers about, and i was impresed. I
don't know how to fit DTE in the existing POSIX MAC functions, but anyway
i think that implementing DTE would be worth it.

> - 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.
That almost done. We should only make some cleanups and intercept
syscalls. I have some thoughts about reorganizing in-kernel MAC support. I
will share them later.

> - 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.
If i understand correctly, BIM is an inverse BLM. So i think, that it
would be easyly implemented.


> - 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.
Another one MAC protection mechanism may be the limited
(restricted?) execution environment. I mean that even if user have access
to /bin,/sbin,/usr/bin, etc... he can execute only specified by an
administrator programs. This can be emulated by an ACLs, but it's to
difficult to pass through all system executables and trace them. And the
second - user can (theoreticaly) create selfowned executables, which would
uncontrolable by admin for some period of time. So if there would be some
structure limiting execution to some subset of system binaries, user can't
be able to execute something evel at all. 

> - 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?
Now my thoughts about reorganization fo in-kernel MAC support. I propose
no to include MAC labels as an additional struct proc variables. I think
that it would be much more better to use queues(lists) of labels inside
MAC modules. So we will not modify hardly the base system and, after
making some in-kernel MAC interfaces, there would be a possibility of
using third party MAC modules.

Packets, routing, networks ... Maybe we can look at TSIX papers to find
out how to make it? I tried some time ago to make passing of peers mac
labels, but it was too difficult for me.

> 	- 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.
My first MAC implementation has floating labels. But Casey show me the
right way. ;-) Floating labels may fly away and you can't catch them.
But anyway - i think that access control to process shared memory can be
made through page faults with operation analysis. Maybe i'm wrong and that
is impossible, but anyway it will affect perfomance dramatically.


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