fresh mac code report

[Robert Watson]

I've CC'd this to trustedbsd-discuss, since there may be some useful
opinions there; hope you don't mind.

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

(2) How we provide for continued correct management of the labels during
    upgrades.

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.

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

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

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