RFC: Requirements for MAC policies and implementation

[Magosányi Árpád]

A levelezőm azt hiszi, hogy Robert Watson a következőeket írta:
[]
> > -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.

In rsbac, there is Fisher-Hübner model, mls, and rbac, and some other things. 
My problem with it that it is orthogonal to the capability system and
does not have ways to virtualise the namespace. Because of these problems
it is very hard to use it on a general-purpose system.

I have found a paper which I found of great value on introducing MAC
modells. It is basically says that not just Biba and Bell-LaPadula are
equivalent, but that you can implement both (and any other lattice based 
access control model) of them when you have support for only one of them.
(I don't know if the above holds for the real thing, as there are several
implementation details, and there are several refinements of the modell)
Ravi S. Sandhu: Lattice-Based Access Control Models
http://heavenly.nj.nec.com/did/87719

[]
> 
> 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
[This moldy thing is a nice idea]
> 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.

I don't see the ipc usage of /tmp a serious problem, it can be done
with "traditional" directories, and upgrading is relatively rare
compared to working on one security level.
However it might be interesting thinking of ways to extend the moldy
directory model, like using CAP_DONOTMOLD.

[]
> 
> 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.
> 

There is one difference: If you have a controlled multi-level zone,
with the packet filter approach you can associate different labels
based on (say) source address, down on the packet filter layer.
So your networked applications don't have to be mls-aware.
(controlled:= there is assurance that address spoofing is not possible)

[dynamic revocation]
> 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.

I see the problem now. There are two approaches I can think of:
- forced deallocation of the resource
- denying operations on a resource
The first seems to be a more complex operation, and as such it have
performance impact on the label switching.
The first is more straightforward, and means that there should be more
access control point than with the one, which means performance impact
on the operation. So the performance impact seems to be greater with this
option. But the first one seems to be really hard to implement.

> 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.

In medusa, the scheme is very easy: There are several attributes of a process.
You can define a callback for filesystem objects, which based on its attributes
can redirect the access to another filename. It works on the vfs layer, I guess.
Medusa is a generalised framework, with C-like configuration language, not a
MAC modell implementation, but have the capabilities to implement simple MAC
policies. And it implements redirection only in the filesystem name space,
but for e.g. sysv IPC it would be also very helpful.

-- 
GNU GPL: csak tiszta forrásból
To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message