Blocking root from changing labels

[Chris Costello]

On Sat, 18 Sep 2004, Payment Online wrote:

> Are there practical methods of blocking root from changing biba/mls
> lables on objects?  Right now I'm thinking of disabling su and only
> allowing root to login at the console.

   This should probably be possible.  From the login perspective, you can
instruct login(1) to associate a specific label to root's login class.
See the 'login.conf' man page for details on configuring this.

   I understand that you want nobody to be able to su(1) to root.  If you
want anyone logging in as root (via its login class), you want that
session's label to be set to "biba/low" etc., correct?  By giving all of
root's sessions low integrity, you are ensuring (among other beneficial
things) nothing it runs can modify anything's label.

> Also, if anyone wants to comment on my first attempt at using MAC to
> protect a database server.  I loaded the partition and biba modules,
> setting most of the system at biba/high, the network interface at
> biba/equal(equal-equal), and /var and /tmp at biba/equal.  I also set
> some of the /dev entries at biba/equal.  The database server user
> label is biba/low, and all the database files are biba/low.  Now this
> seems to pretty much lock any other user from getting any access to
> the database files directly, but what am I really gaining by using MAC
> in this setup that I couldn't do with ordinary file permissions?  I
> guess one thing would be that if there was a bug or misuse of
> postgresql that elevated it's permissions to root, the biba labels
> would block that.

   In this case, what is important is the running pgsql's process label.
If any elevated privilege occurs within pgsql, /var, /tmp, and parts of
/dev are mutable by pgsql (giving those objects a 'biba/equal' exempts
them from any protection by the biba security policy).  The remainder of
the system depends on the labels of the objects involved.

   I want to say that giving the database server and its associated files
a low integrity will not do much.  Applications access the database
remotely via the network (non-protected), locally via lo0 (apparently
non-protected), or via shared memory (non-protected), so the integrity
label on the database files will not actually follow the data into the
connected application.

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