mac_partition and /sbin/init

[Kenny Freeman]

Robert, thanks! I was wondering how partition/none was treated in the source. 
It probably would have taken me another few hours of digging through the 
different sources to figure out that 0 was actually none. Is there any way 
that the getpmac output could be rewritten so us simple folk don't get 
confused? ie. partition/0 -> partition/none. Well, that or put it into the 
man pages. I've been fiddling with this for a few evenings now. I guess I'm 
going to have to put in a few rc scripts to start these jails up. Using the 
jail util like:

jail_dnscache_exec="/usr/sbin/setpmac partition/1 /bin/sh /etc/rc"

 I get permission denied errors when setting the partition to anything other 
than none, presumably because the process has already been put inside the 
jail when the setpmac util is run. 

Oh, this has probably been asked many times before.. Where would one find some 
usefull documentation on using biba, lomac and mls? I mean more about how to 
develop policies to secure a system with them. I've looked around at some 
trusted irix docs etc but haven't really found anything readable yet. Thanks 
for the other mailing list suggestions. I tihnk I will subscribe when I get 
some time.

-Kenny

On September 24, 2003 08:41 pm, Robert Watson wrote:
> On Wed, 24 Sep 2003, Kenny Freeman wrote:
> > Hello, I haven't received any emails on this mailing list yet. Kinda
> > makes me wonder if it is dead or just low traffic...Should I be asking
> > this on another list perhaps?
>
> Not dead, just low-traffic :-).
>
> > I'm curious about the mac_partition module and why it somehow decides to
> > put /sbin/init into partition 0 instead of partition none, which is what
> > I would like. I'm running about a dozen jails on a test server and would
> > like to partition jail processes into a seperate partition per jail.
>
> mac_partition treats 0 as the none partition.  The basic logic for
> inter-partition access control is:
>
>         if (SLOT(subject) == 0)
>                 return (0);
>
>         if (SLOT(subject) == SLOT(object))
>                 return (0);
>
>         return (EPERM);
>
> I.e., if the subject is in partition 0, access control isn't modified.  If
> the subject is in the same partition as the object, fine.  Otherwise,
> generate a protection error.
>
> > To do this I have created seperate login.conf classes with
> >
> > :label=partition/x,mls/low\(low-low\):\ entries.  I have also created
> >
> > entries that have :label=partition/none,mls/low\(low-high\): for root
> > and default. I guess this doesn't take affect until init decides to run
> > /etc/rc
>
> Per-user labels are set as part of the user context during a login or
> related event.  Right now, the scenarios where labels are set are events
> such as:
>
> /usr/sbin/sshd switches to the user's account for their login shell
> /usr/bin/login switches to the user's account for their login shell
> /usr/sbin/cron switches to the user's account to run a cron tab entry
> /usr/sbin/sendmail switches to the user's account for mail delivery
> /usr/sbin/inetd switches to a user's account to run a daemon as them
> /usr/bin/su switches to the user's account to run a shell
>
> If you're starting programs using rc, you'll need to manually set the MAC
> label, either by using su, or by using setpmac.  I generally use setpmac
> to run specific commands at a specific label:
>
> /usr/sbin/setpmac mls/low touch /tmp/as_low
>
> > I am unable to set the processes partition when the base system init is
> > in partition 0 it seems... suggestions?
>
> The logic to check a relabel request for partition is as follows:
>
> (1) A target partition of "0" is treated as a no-op, so no change will
>     occur.
>
> (2) If the new label is not "0", then privilege is required to change the
>     partition label.
>
> A good test is:
>
>   # setpmac partition/1 ps ax
>
> or:
>
>   # setpmac partition/1 getpmac
>
> BTW, if you're interested in commit/merge activity relating to the
> TrustedBSD work, there's a trustedbsd-cvs mailing list, which picks up
> most branch commits relating to TrustedBSD (including the main MAC branch,
> ACL branch, and SEBSD branch).  Merges to the FreeBSD tree can be seen on
> the FreeBSD commit mailing lists.  More traffic on trustedbsd-discuss
> would be welcome, of course, also :-).
>
> Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
> robert at fledge.watson.org      Network Associates Laboratories
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: signature
Url : http://lists.freebsd.org/pipermail/trustedbsd-discuss/attachments/20030924/878cbcfe/attachment.bin