RFC: Requirements for MAC policies and implementation

[Robert Watson]

On Wed, 20 Sep 2000, [iso-8859-2] Magosányi Árpád wrote:

> -Low water mark model

Since Tim Fraser is on the mailing list, I'd be interested in hearing his
opinions on the topic, as he has implemented LOMAC on Linux.

> -Fisher-Hübner privacy model

I'm not familiar with this model -- could you give me a reference I can go
chase up?

> -Role-based access control

Do you have any worked examples of RBAC in a UNIX system I could take a
look at?  It has always struck me that the current use of groups in a DAC
sense strongly resembles roles, and that with minor modifications to the
group semantic (possibly entirely within userland) you could have a
moderately useful RBAC system, albeit somewhat on the DAC side.  I can see
a variety of ways in which it might be implemented from a MAC sense, but
no practical experience to base design choices on.

> I am increasingly on the opinion that if you want to implement some
> sensitivity oriented MAC, like Bell-LaPadula, there are also some
> features that should be there to make a system work with only
> light modifications. One such issue is the virtualisation of namespaces.
> If you use sensitivity oriented MAC combined with non-intersecting partitions,
> it is all okay. But if you use it in one namespace, there are problems
> like 'what is the label of /tmp?'. The file redirection feature of Medusa
> (if it would work) is an elegant way to resolve these issues. (another way
> is to make all programs aware of the situation, but I think it isn't
> feasible even with the closed development model of BSD.)

This is, to some distinction I was getting at with the partition case --
today's jail() works by limiting the namespace scope of the process
(chroot(), inter-process, and network limitations) and by limiting the
privilege scope of the process (removing the opportunity to break the
namespace scoping).  This is an extremely useful subset of a mandatory
policy, and worth optimizing for.

The general MLS/Biba mechanism does call for a solution to the shared
readable+writable directory case in a single namespace.  I'm not familiar
with Medusa, but can speak to "Moldy" (Multi-Level Directories -- MLD)
directories in Trusted IRIX. In TRIX, a type field in the directory's
label indicates that it is moldy, and namei() performs an expansion during
the namespace traversal creating a new directory with a unique name
reflecting the label of the process, and labeled as such.  This has some
interesting properties, and does preserve the integrity/sensitivity
protection scheme, as well as potentially being applicable to other
systems.  That said, it's not an ideal solution, as it eliminates /tmp as
a mechanism for legitimate transfer between levels (read down, write up).
Part of that is more of an issue with /tmp being multi-use.  For purely
temporary storage (and not IPC), MLD directories seem fine.

> > - Labeling Issues
> 
> 	I think the network related things could be adressed elegantly
> 	from the packet filter side. I am thinking of something like
> 	the "fwmark" feature, where the packet filter rules can mark
> 	incoming packets. The network sockets could be labeled by
> 	the creating process (either implicitly or explicitly),
> 	and the implicit narrowing and the access control could be
> 	done using the packets' label. The labels of an interface
> 	could also be a factor in the computing the label of a packet
> 	or a socket, but I feel it is unnecessary if we base the marking
> 	on the packet filter rules (you can be selective based on 
> 	interface there).
> 	From the flow control point of view an interface or a network 
> 	socket is a communication channel, and not a system object.
> 	And as such, they labels should be designated (either implicitly
> 	or explicitly) by the authorized administrator, and the access
> 	to them should be governed by the importation and exportation 
> 	rules.
> 	This means that the labels associated by the packet filters should
> 	be labelsets instead, which can describe the minimal and maximal
> 	label of an interface, and there are rules which can narrow
> 	a labelset of an object/channel.
> 	[Add a distinction between data and control, define sensitivity
> 	and integrity rules for both, and you will get Zorp's access
> 	control model:]

This is an interesting model, and I believe Argus Systems implements it in
their PitBull product.  It provides many nice properties, but I was
worried about some of the details of the implementation: handling of ICMP
packets, etc.  I see packet matching techniques as more congruent with
non-overlapping partitions than necessarily in environments where TCB
member processes make decisions rather than the kernel (i.e., sshd+login
on a host making the decision that this set of children processes will
have high integrity rather than low integrity).  The label scope
mechanism you describe addresses this issue to some extent and also
has nice properties.

Packet filters also see a performance hit, something the FreeBSD community
is sensitive to: cost for processing filters can be linear on the number
of rules in the worst case, and labels on mbufs will increases the memory
load, et al.  Tagging instead interfaces imposes little cost at run-time,
with a constant (low)  cost when packets are delivered to the socket,
given the struct ifnet pointer in the mbuf.

However, that doesn't mean I'm strictly opposed to it--probably i would
make sense to think through the design of both techniques and see if they
can serve in both 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.
> 
> The TCSEC interpretation is clear abut revocation:
> 	You are not required to promptly revoke a resource which is given
> 	to a user if her rights which made her eligible to get the resource
> 	has been revoked. So you can wait with freeing memory
> 	until the process exits, and in a static label scheme you
> 	are not even required to knock out that label from the proc
> 	structure when it is changed in "/etc/passwd".

This is relatively safe in statically labeled environments, where labels
on objects are assigned at creation but changed infrequently (and only
changed explicitely, allowing the subject making the change to determine
if it makes sense.)  In a low water-mark model, I think it would be
desirable to have changes propagate fairly quickly, or you lose the
benefits of the scheme.  I.e., is a subject touches a low-integrity
object, you would like to it to lose write access to high integrity open
files.  This is one of the downsides of a scheme allowing floating labels
:-).  In environments with entirely static labeling, revocation is not an
issue.  In environments where labels don't float constantly, but
upgrade/downgrade operations are possible and useful, it may be acceptable
to make revocation an expensive operation, or to ignore it (but carefully
document it).  I would imagine that revocation on normal file descriptor
based file access would be relatively straight forward, but propagating
those changes via the VM system to catch memory maps and shared segments
would be more painful.

> > 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. 
> 
> I just wanted to suggest some generalized framework approach.
> In this case I guess this implementation shall choose one sensitivity
> (Bell-LaPadula of course), and one integrity (Biba or low water mark 
> comes to mind) model, augmented with capability handling , packet filter
> change and file redirection.

Sounds good to me.  My intent was to initially support one sensitivity
scheme, one integrity scheme, a special optimization for partitioning,
capability handling to exempt processes from the schemes and allow
upgrade/downgrade operations, some labeling of network objects, and
handling of IPC objects.  Could you talk a little more about issues with
file redirection?  For normal I/O redirection on a statically labeled
system, I would think that fell out by virtue of file protection.  In a
floating label system, such as Tim's LOMAC, IPC objects such as pipes
between processes need special handling to retain their usefulness, or all
processes in a pipeline lose integrity as it works its way up.  Which is
correct according to the model, but impractical in real-world systems,
where it is desirable to handle streams of terminal data as unlabeled
despite labeling the pipes they pass through.

  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