fresh mac code report

[Ilmar S. Habibulin]

On Fri, 18 Jan 2002, Robert Watson wrote:

> I've CC'd this to trustedbsd-discuss, since there may be some useful
> opinions there; hope you don't mind.
That's ok, maybe i should post to -discuss such messages.

> On Fri, 18 Jan 2002, Ilmar S. Habibulin wrote:
>
> > Well, can you insert attached commands to installworld step? You are
> > using diskless boots, while i'm using local filesystem. So i had to find
> > these commands and execute them by hands.
>
> Hmm.  I think there are two requirements we need to address here:
>
> (1) How we automate the transition from a "traditional" FreeBSD
>     configuration to one supporting MAC ("TrustedBSD", if you will).
I think, that nessessary labels can be set during installworld step with
error ignorance. Just to make something work. I thought only about
insertion such commands in Makefiles of trustedbsd_mac branch.

> (2) How we provide for continued correct management of the labels during
>     upgrades.
That's an interesting question. imho, update procedures should set
nessessary labels themselves. The only problem here is if administrator
sets his own set of labels, that is incompatible with the default ones.
Then update procedure may check label of object and if it is not something
default - ask operator interactively.

> My temptation in the short term is to support some sort of
> ENABLE_MAC_INSTALL flag in make.conf (or make installworld command line)
> that will apply appropriate labels on a file-by-file basis during the
> installworld, pretty much as you suggest.  For the long-term install,
> we'll also need to have a tool to walk the filesystem and modify labels to
> bring them in line with the default policies.  Keeping the two policies in
> sync will be important, and suggests that it might be desirable to have
> them originate from the same database, and then be processed in both
> situations.  Perhaps a tool not unlike mtree for binary labeling.
Well, lets hack mtree. What's a problem. IMHO, mtree is one of the perfect
solutions, because it is one of (or the only) tool which is used to
controls integrity of filesystems and file attributes.

> > I have problem - in order to use ssh(scp) and X(xauth) i had to switch fs
> > enforcement off :(. Here is log messages:
> > Jan 18 17:48:48 ws-ilmar kernel: vaccess_mac returned 13 for 272 (ssh) on unknown
>
> 'unknown' frequently results from access to either a removed file, or a
> /dev entry, as /dev doesn't use the namecache.  If I had to guess, that
> would be an attempt by scp to talk directly to your current terminal.
Ya, maybe it is trying to ask password. ;-)

> Right now, the login process doesn't update the terminal label, but since
> we enforce only at open(), the inherited reference can be successfully
> used.  As we move to enforcement at read/write on terminals, and for
> situations like this, we'll need to have relabeling working.  For MLS and
> Biba, simply setting the label based on the subject label should be
> straightforward; I'm less clear for TE how the label should be generated.
Well, i'll look at login. Now what to do with TE - i don't know. I've read
some TE docs and came to conclusion, that TE is a very general policy, so
you can teoretically specify any type of access to any type of object. We
have everything except experience in building systems based on TE.
Unfortunately i was anable to get usenix96 TE paper, which describes the
use of TE in UNIX system. Maybe you can get access to it?

> > Jan 18 18:00:16 ws-ilmar kernel: vaccess_mac returned 13 for 344 (xauth) on /usr/home/ilmar
>
> I haven't tried using X stuff with the MAC implementation as yet.  Is this
> just the xauth that happens on an incoming ssh, or is this associated with
> something else?  If I had to guess, it would be that xauth is getting run
> at the wrong time relative to the labeling operation: the OpenSSH code
> does some fancy uid twiddling and currently the MAC labeling doesn't
> reflect that.  To support alternative security models, the OpenSSH code
> probably needs to be restructured so that it sets the credentials *once*
> when it has decided what they should be, rather than swapping back and
> forth several times.  I suspect fixing this, however, will be a fair
> amount of work.  There are some related problems with port forwarding
> also, I think: the port forwarding is authorized based on a userland root
> check, rather than setting appropriate credentials and then having the
> kernel perform the authorization.  This will need to be fixed to support
> both MAC and CAP properly, as well as possibly Audit.
No, i'm not using ssh for X, just startx from console. I think that
biba denies access, because process has biba/low and home directory has
biba/high, and as i understand xauth trys to write to some file (or create
one) in my home directory.


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