Subject: Re: SE Linux vs SE NetBSD !!
To: matthew green <mrg@eterna.com.au>
From: Travis H. <solinym@gmail.com>
List: tech-security
Date: 08/25/2006 18:52:53
On 8/25/06, Travis H. <solinym@gmail.com> wrote:
> To emulate SELinux policies with Unix permissions, it requires a lot
> of UIDs, and some of that policy is in /etc/passwd, and some of
> that policy is in SUID programs, and some of that policy is in the
> file system permissions and owners.  With SELinux it's almost
> all in the policy file.  Sure, it may be macro-expanded to 50,000
> rules on a typical system, but how many files do you have on your
> file system?  What do your GUI tools for managing permissions
> on every file in your file system look like?

Actually now that I think about it, SELinux attributes are even more
data stored on the filesystem, but it is generated from an SELinux
policy file.  It's not done in realtime; as a matter of fact, it's
very time-consuming to relabel the filesystem.  One neat thing is that
you can set up a cron job that reports any differences,
and it can heal itself, a lot like mtree.

I think what it boils down to is that the granularity of SELinux
permissions is much smaller than that of traditional Unix, so you can
give permission to talk on the network, or append to a file, or
perform an ioctl, and so on.  I'm a control freak, so it appeals to
me.

I have only looked at the systrace documentation, and used it when
building FreeBSD ports, but it seems like you could do similar things
with systrace.  Both have a learning mode where you can learn what
permissions your programs need.  I heard the systrace code wasn't
written in a particularly clean manner, and rumors that it was
exploitable in some cases, but I don't say that from first-hand
experience, and I think highly of Neils Provos (that's who wrote it
right?).  I also heard it wasn't being actively maintained, which is
unfortunate.

I wouldn't want to have to come up with a policy to cover a huge
network abomination like sendmail, maybe not bind either, but programs
that follow the "do one small thing and do it well" policy are fairly
easy to write policies for.  I heard from Tresys that the best
policies come when the application is written with SELinux in mind,
that by being SELinux-aware when writing programs can be of benefit.
-- 
"If you're not part of the solution, you're part of the precipitate."
Unix "guru" for rent or hire -><- http://www.lightconsulting.com/~travis/
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484