Blocking root from changing labels

[Payment Online]

On Mon, 20 Sep 2004 22:29:12 -0700, Chris Wright <chrisw at osdl.org> wrote:
> * Payment Online (snacktime2 at gmail.com) 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.
> >
> > 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?
> 
> Ordinary file permissions are discretionary.  So, you've added a
> _mandatory_ access control scheme which can limit exploit exposure beyond
> what the DAC bits can do.  This could be especially useful if the machine
> is providing multiple services (not just database server).
> 
> > 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.
> 
> Yup.  Although, my experience is that this is not the likely attack
> vector.  In fact, it's often the database itself that contains the
> valuable information.  The database processes will require read/write
> privilege access to the files (or raw block devices) that contain the
> tablespaces/table data.  And it's now up to the applications accessing the
> database to be secure.  Esp. in the case of a multi-tiered architecture,
> where an application (which could be a poorly coded set of CGI scripts
> on an app server) could be tricked via typical sql-injection attacks to
> commit bogus transactions.
> 

Agreed.  We actually just went through a security audit for the visa
CISP program (we are a payment processing house), and it's funny how
much emphasis is put on the traditional firewall/router filtering
protections, and very little on application level security.

Anyways,  one of the primary things I am looking at in securing the
database server and our application servers is protecting the private
keys used to decrypt data.  Right now the application servers are
started manually and the password entered at the command line by a
real person,so the private key password is in memory but not stored
anywhere else.  The encrypted private key is stored in a function in
the database server.  Getting login access means getting around ssh2
with cryptocard smartcard authentication, but the password and private
key are the weak points as far as I can tell.  The web applications
can only be accessed if you have a certificate issued by our CA plus a
username/password authenticated against our kerberos server.

Chirs

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