fresh mac code report

[Brian F. Feldman]

"Ilmar S. Habibulin" <ilmar at watson.org> wrote: 
> On Fri, 18 Jan 2002, Robert Watson wrote:
> > 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.

How about adding "command" support for mtree, as a more generic way of 
approaching it?  I do like the idea of using mtree to install attributes, 
regardless.

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

You should be able to access any proceedings, really, for free from Usenix.  
Are you perhaps looking for the 96 Security Symposium DTE paper?  You can 
get a copy of that at:

http://www.usenix.org/publications/library/proceedings/sec96/walker.html

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

If SSH were to actually attempt to support management of credentials above 
and beyond standard UNIX DAC, it would probably have to be rewritten first.  
The current SSH implementations are absolutely not conducive to this; and 
indeed, it's probably quite bogus of a design for the implementation to want 
to swap between different sets of credentials in the first place (not in the 
least because attempting to swap between MAC labels could easily be totally 
inappropriate for a given MAC system.

As far as XFree86 goes, the xdm model is something like:

xdm needs to
  read from /etc and /usr/X11R6
  fork and execute /usr/X11R6/bin/X
  execute PAM modules
  read (execute) $HOME/.xsession
  create/write $HOME/.xsession-errors (later inherited as fd 1 and 2 by child
   X clients specified in .xsession, and fd 0 as /dev/null)
  create/modify $HOME/.Xauthority by default (alternately, $XAUTHORITY may be 
   anywhere)
  /usr/X11R6/bin/X needs to
    open /dev/io
    modify /dev/mem
    read any input devices
    bind and accept from a local stream socket (/tmp/.X11-unix/X$n) and/or a
     TCP stream socket
    read/write on accepted sockets
    create/modify /tmp/.X$n-lock

Note, of course, that xdm initially runs in its initial context, and 
performs later operations (.xsession and beyond) after having initialized to 
the user's context.  XFree86 inherits its permissions from the initial xdm 
and does not revoke them.

The startx model is somewhat different, and is on the order of:
startx needs to:
  execute xinit
  xinit needs to:
    read from /etc and /usr/X11R6
    fork and execute /usr/X11R6/bin/X (or Xwrapper)
    read (execute) $HOME/.xinitrc

Note that in this case, startx starts with just the user's credentials, and 
permissions needed by X are gained generally from a setuid flag on it or 
Xwrapper.  Also, fd 0, 1, and 2 are all inherited from the context of the 
initial startx executed and not modified, so will generally be the terminal 
device itself.

-- 
 Brian Fundakowski Feldman           \  FreeBSD: The Power to Serve!  /
 green at FreeBSD.org                    `------------------------------'




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