some questions (Re: mac-0.5.diff)

[Robert Watson]

On Thu, 27 Sep 2001, Ilmar S. Habibulin wrote:

> Well, personally i can't understand what is your partition model. Once
> you said that it is something like jail(2), but more general. There is
> now some new jail project, so you propose something more general?

The general observation is that the jail() code resembles a MAC model,
since it enforces mandatory restrictions between processes, and for
processes operating on system and IPC objections.  The partition MAC
scheme is an intent to encapsulate that policy behind the same API used to
insert MAC hooks in the system.  I'm not entirely convinced this is
useful, but it does make one think more generally about the hooks. 

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

> Ok, i'll try to explain in a few words. IPSO(130) has 16bit level field,
> 16bit compartment field, 16bit handling restrictions and 24bit
> transmision control fields. Last two fields must be obtained from some
> US DoD documents. RIPSO(revised IPSO, also option number 130) has 8bit
> level field and variable length protection authoritity flags field,
> which is not compartment, so i don't understand what it is, but it is
> very US specific.  There is also extended IPSO defined (133), which has
> 8bit additional security information code field and variable length
> additionl security info field. For each additional security info code an
> RFC should be published, but i did find one. So i don't know what it is.
> And now CIPSO (option number 134). Each option can include one or more
> named tag sets.  Named tag set includes named tag set name and one or
> more security tags.  There are 5 security tag types defined. IMHO MLS
> 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.

> > their keyfile, so password authentication has to be used instead.  There
> > are no doubt hundreds of other little "gotchas" lying around.  Also, right
> > now, we don't have MAC label support in devfs, so there's no MAC
> > protection for tty's stored in devfs (et al).  Brian Feldman of NAI Labs
> 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().

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

> > One thing I think we probably do need to do is move to a seperate /etc/mac
> > database: login.conf is convenient, but has a lot of baggage.  I'd like
> > for the database to be able to express concepts such as allowing the user
> > to select a role at login, so some look at prior art is probably also
> > called for there.  Thomas Moestl prototyped an /etc/capabilities database
> > in the new capabilities code, and I think also tweaks to su to use it, so
> > that's probably a good starting point.
> Well, i had /etc/mac subdir with levels, compartments and userdb files.
> levels and compartments were levels and compartments text representation
> names, and userdb - user labels.

I have that tarball around somewhere, and will try to look at that shortly
also.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services



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