FYI on TrustedBSD documentation updates, other news

[Robert Watson]

On Mon, 21 Apr 2003, Ilmar S. Habibulin wrote:

> On Sun, 20 Apr 2003, Robert Watson wrote:
> 
> I have some questions.
> 
> > - Move to a label database separate from the login class database to
> >   improve flexibility.
> Would compartments have human-readable format in text representation?

I assume from this you believe the current format is not human readable
:-).  Changing the format wasn't what I specifically had in mind as part
of this action item, although adding new levels of indirection would
certainly be possible.  Right now, the mapping is:

  user -> login class -> label

I'd like the ability to express things more centrally (i.e., not scattered
over the login database), without tying labels to things like resource
limits.  I'd also like the ability to specify multiple sets of labels the
user could select from at login.  I haven't really tried prototyping it as
yet, but either of the following might be a possibility:

/etc/mac/userlabels (simplest version)

  user1: mls/high:1,biba/low
  user2: mls/80,biba/low

/etc/mac/userlabels (multiple labels with first being default)

  user1: mls/high:1,biba/low mls/high:2,biba/low
  user2: mls/80,biba/low

/etc/mac/userlabels (level of indirection)

  user1: interesting_compartments_one interesting_compartments_two
  user1: interesting_compartments_two

/etc/mac/labelsets (here's the target of the indirection)

  interesting_compartments_one: mls/high:1,biba/low
  interesting_compartments_two: mls/high:2,biba/low

None of these, though, would perform the substitution on the output of

  ls -lZ /tmp

With a movement towards a dynamic /bin and /sbin, putting that kind of
substitution in gets a lot easier, though.

> > - Revisit out handling of TTY labels as set at login, our current approach
> >   has a number of serious limitations.
> Can you describe these limitations please.

There are a few operations that occur on TTYs that are of interesting, the
most important being "prepare tty for login", "prepare tty for user", and
"scrub tty".  Often, the first and third are the same.  The abstractions
for handling ttys are fairly poor as they're used in a lot of different
places, and in different ways.  To give you a sense of the variation,
here are some examples:

getty
	Opens specific tty, initializes with login_tty()
	Manually resets tty mode (0600), ownership (0:0)
	chown(, 0 ,0); chmod (, 0600)
	revoke()

login
	Open tty comes in via stdin/...
	Manually resets tty flags (0)
	Manually sets tty ownership (uid:"tty", falling back to gid)
	Also calls login_ftbab()

rlogind
	Opens tty using forkpty()

	Manually resets tty mode (0666), flags (0, and ownership (0:0) on
	    logout

sshd	(hard to read due to configure stuff)
	Opens tty using openpty()
	Manually resets tty ownership (0:0), mode (0666) on logout

telnetd
	Manually allocates a pty
	Manually sets tty ownership (0:0), mode (0600)
	Calls revoke() on pty slave, sets pty slave ownership (0:0),
	    mode (0:0)
	Manually resets ownership (0:0), mode (0600) on pty and pty slave
	    on logout

I also took a look at xterm, its source code also obscured by conditional
compilation, and discovered that it uses openpty() on FreeBSD (or should
if it doesn't), that it doesn't rely on manual pty mode/ownership setting
(unless configured to do so), and that it possibly manually resets the pty
settings on logout.

Right now in the MAC branch, we store two labels in /etc/login.conf for
each user: "label", and "ttylabel".  At login, we attempt to set the tty
label as part of the tty configuration, and the user label as part of the
setusercontext().  However, I suspect we don't properly handle a number of
cases involving pty handling, as well as the label reset process.  You'll
notice this problem in using xterm, as the label will get set when xterm
starts to the user's label, but never reset, which means that the pty may
not be reusable by processes at other levels when using MLS.  We need to
talk through all the tty management code in detail and work out how it
should behave.  One of the things we're missing is a good notion of what
the initial label should be, and what to reset it to when done with a tty.

> > - Add variant symlink support to handle poly-instantiation handling of
> >   /tmp, et al.
> Is it something instead of MultiLevelDirectories? Maybe it is better to
> implement MLDs?

Well, my thought was to use it to implement an MLD-like notion, with or
without the mkdir:

   ln -s /tmp.real/%mls%/%biba% /tmp

And give policies the opportunity to substitute for names as necessary.  I
prototyped this locally, but the patches will need updating.  Then the
question becomes, should there be automatic directory creation -- the
answer is made a little more difficult because FreeBSD now supports shared
and exclusive vnode locks, and we'll need to make sure that we hold an
exclusive lock if we want to automatically create directories.  There are
also some interesting questions about the credential used to create the
instance directories, what labels to set, etc.

> > - Improve networking integration for carrying labels over the network,
> >   IPsec support, etc.
> There is some issue with network packet labeling using IPSEC, which i
> couldn't resolve. I can provide some policy for interoperability of 2
> peers with certain labels. But how to handle Client-Server operations with
> multiple clients having different labels? IPSEC doesn't have functionality
> to transfer label information from client to server. Maybe this should be
> done by some daemons, like racoon?

I haven't really looked closely at the issue, but intuitively, I agree. It
would be nice if the labeling and access control properties associated
with a security association could be negotiated as part of IKE.  I.e., the
IKE daemon would look at the certificates involved and set up the
association based on verified certificate properties ("Ah, this remote
host certificate is for a low integrity client, so label packets coming
out of the SA appropriately").

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Network Associates Laboratories


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