some questions (Re: mac-0.5.diff)

[Ilmar S. Habibulin]

On Thu, 27 Sep 2001, Robert Watson wrote:

> > Ok, just make a choise, i can't help you because i do not understand
> > what is partition and i don't even imagine how would MLS, BIM and DTE be
> > used togather. I suppose it is not a simple task to setup such a system. 
> > Maybe Tim will tell us something more about use of DTE with other
> > security models? But i don't think, that such stuff as Biba label, or
> > DTE label should be included in packet label. Maybe i'm wrong, thinking
> > that it is a site attributes, not network.
> MLS + Biba seem to work well together, addressing the  largely independent
> (and easily composable) confidentiality and integrity concerns.  With
I understand. Biba and BLM can be used togather. I wrote about Biba, MLS
and DTE togather. I think of DTE as being much more close to integrity
control models. So DTE and BLM should also work togather just fine.
Problems begin to appear when you try to use these models all togather.

> compartments, it's possible to better represent certain "need-to-know"
> policies.  However, it is still pretty far from being able to express a
> number of useful role-based models, or providing a mechanism to get closer
> to least privilege.  By throwing TE into the mix, you can represent a
I think that any role-based model could be implemented using MAC and DAC.

> number of more useful policies.  From the perspective of packet labeling,
> I think going with MLS and Biba is fine -- I'm not sure existing TE work
> has addressed the packet label issue much, although I know DTE has.  Since
> these policies are so flexible, deciding how to export something useful
> (and then import it at the other end) is an unsolved problem.  For now, I
> think carrying the label information down the stack to do per-interface
> access control is sufficient, and just dropping additional label
> information on going out a multi-level interface is OK.  It may be that
> the right approach is to use IPSEC tunnels as the vehicle to implicitly
> label some of these additional attributes.
I'll read IPSec and IPv6 standards, but not right now. I'm a little busy.
And i think that existence of some implementation is the great step
forward. 

> > and BIBA can use type 1 - thare are 8bit security level field and
> > variable length bitmap (up to 245 bytes). Type 7 is variable at all. So
> > if you have time, look RFC 791, 1038, 1108 and FIPS 188. That only
> > covers IPv4. 
> I'll read up on those this weekend.  One question it does raise is with
> regards to mapping potentially finer-grained MLS levels into 8-bit levels.
> It may mean we'd be better limiting ourselves to 8-bit levels if we think
> exporting those levels will be common.  Otherwise, we'll need to have some
> policy mapping local levels into exportable levels.
8bit level values are from 0 to 255. I think that this is enough. Any way
in case of MLS 4 levels are used: Unclassified, Confidential, Secret and
Top Secret. The problem exists with compartments implementation. CIPSO is
limitting their length to 239 octets.

> > That's bad. Then how does anything works? In my 2.2-implementation user
> > access to terminal blocks, if user and terminal (/dev/ttyv*) labels were
> > not equal.
> Right now enforcement of MAC policies on files is done inside the UFS
> implementation, and within procfs, so isn't implemented for devfs, or NFS
> (or others).  I have some initial patches that provide generic
> single-level labeling support for file systems that don't support MAC, and
> hope to get that into the next patch.  It involves expanding the use of
> vaccess() a bit so that the vfs mount is passed in for the vnode when a
> decision is made, so that the mount label is available.  We probably also
> need a VFS call to change the mount label (right now the default is to
> copy the label from the credential authorizing the mount operation) --
> perhaps vfs_relabel().
Take a look at my old work. I have a higher level access control code,
which intercepts system calls and makes decision based on subject(process)
and object(file,socket,pipe,ipc,etc) labels. So in FS case - if FS support
labels, it will provide access control mechanism with the current label of
the file, or if not - the label of file would be some default label. So
you need not to hack every FS code to make MAC hooks there. Just teach FS
to import/export labels and that's all.

> > > Probably not at this time, since I'm pretty sure the current tools need to
> > > be largely reimplemented.  One thing it would be nice to have is -R
> > > support for setfmac :-).
> > I've used cp sources with fts(3) to make this.
> Sounds good.  Do you have patches I could apply?
Again, look at my old work. If there is no setfmac.c, i can send you.
I can send you kern_mac.c also.


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