some questions (Re: mac-0.5.diff)

[Robert Watson]

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

> On Wed, 26 Sep 2001, Robert Watson wrote:
> 
> first of all - how capabilities integration is going?

It's moving slowly -- I've committed more support components for
capabilities to 5.0-CURRENT, including the complete userland library code,
and more of kern_cap.c.  The big chunk of necessary committing is not yet
quite ready -- I need to get some more broad review of the
suser()->cap_check() changes.  I hope to have a new capability patch up in
about a week or so--Thomas Moestl has made substantial progress on it, and
I'll spend some time getting it ready for distribution.

> > Multi-Level Security, and a custom "partition" scheme.  This patch does
> > not include recent progress made by Ilmar in the network labeling/access
> > control space, nor non-hierarchal MAC categories.
> I will port my work in -current and send you my patches ASAP, maybe in a
> week. And what about non-hierarchical categories? I've checked RFCs 1108
> and 1038 to see, if they have something, that will satisfy our needs. But
> it's funny or not - these RFCs are more US-specific, that FIPS 188 is. ;-)

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

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

> > Disclaimer: If you run it, this patch will hurt you, I promise.  Don't do
> > this on a machine you don't want to sacrifice to the good of the cause.
> You scared me to death. ;-)))

:-)

Many things seem to work fine on my testbox.  One problem I have noted is
that some SSH activities have problems, including using SSH personal keys
to log in as a user with a low integrity label.  When OpenSSH's sshd looks
at the per-user .ssh/authorized_keys file, it swaps to the users
uid/gid's, but not their MAC label.  The result is that it can't read
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
has been looking at revocation of memory mappings, and has had some
success, and that's an area where I'd particularly like to see progress. 

> > 	setfmac biba/low,mls/low,partition/none `find /home/rwatson`
> > (setfmac does not currently have a -R parameter, but will get one in the
> > next iteratin)
> Do you want s/getfmac be internationalized?

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

> > There may be problems with this release (there always are), so expect
> > patch updates.
> Be waiting for... ;-)

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. 

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.

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