some questions (Re: mac-0.5.diff)

[Ilmar S. Habibulin]

On Thu, 27 Sep 2001, Robert Watson wrote:

> I definitely want non-hierarchal support, and need to go look at the
> patches you sent me a while back that implement that.  One thing I'm
> trying to decide is whether or not to take the "partition" model forwards,
> or just spend some time implementing something more general (such as Type
> Enforcement). 
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? 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.

> > So, i will implement CIPSO, but don't know right now what type of
> > security tag should i use. Maybe you can help - what do you think should
> > be included in packet label right now based on MAC model and
> > implementation you have?
> I'm not very familiar with the various IP standards to stick labels in
> packets.  I would imagine it would be necessary to export all MAC
> information in the socket MAC label in the IP option, but the best path
> here is probably to look at what people have done in the task.  Maybe
> someone from SGI can speak to exactly what they put in their IP options. 
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.

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

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

> I'm currently adding MAC label range support, and am looking at some other
> tweaks.  I've had a development tree for a while with a "struct objlabel" 
> structure, which combines the discretionary and mandatory access control
> labels for many common system objects, as well as some general purpose
> access control checks.  The goal there was to provide a general primitive
> to support synthetic file systems (such as devfs) and other object
> maintainers so that protections can be added easily.  I'm not sure yet
> this is entirely the right approach, but I might drop it into the next
> version of the patch to support devfs. 
Will see what it is.

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


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