Hi!
(moving this thread to -security since both authors gave permission to quote)
On 2003-11-29 18:06 +1100, Russell Coker wrote:
> On Sat, 29 Nov 2003 14:21, Pablo Lorenzzoni <spectra@debian.org> wrote:
> > (1) RSBAC - http://www.rsbac.org - Used by Adamantix. It seems to be
> > quite reliable and easy to configure.
>
> But it seems that no-one in Debian is interested in using it. When I packaged
> the kernel patches no-one tested them.
In case you are interested, I did try RSBAC, but not from the Debian
package. Personally I prefer to have the kernel and security patches
installed by myself from upstream source; not because I don't trust
you or want to offend anybody, but because I exactly want to know
what's going on there.
RSBAC has a lot of nice features and seems pretty well designed, but I
do not use it because of the following:
- Security policies (ACLs etc.) are altered by calling command line
programs which modify binary files. I don't quite like that, I'm
more fond of keeping everything in a single human-readable
configuration file. But that is really a matter of taste.
- It needs an extra account ("security officer" with UID 400) which is
a pretty bad idea IMHO. Since once you are SO (cracked/sniffed
password etc.), you can alter anything which seems like a giant
security risk to me.
> > (2) PaX - http://pageexec.virtualave.net/ - Used by adamantix and
> > Hardened Gentoo. It implements the unexecutable memory segment (much
> > like exec_shield, but with steroids), and page randomization. These
> > techniques have being used in OpenBSD for long (not quite the same,
> > though...)
> >
> > (3) Exec_shield - somewhere under www.redhat.com - Implements the
> > unexecutable memory segment. I know nothing about this patch...
>
> We've been through this discussion at great length on debian-devel...
ACK. I won't repeat anything here. Also I did not try out these by
myself.
> > (4) grsecurity - http://grsecurity.net - Use their own implementation
> > of Role-Based Access Control and ACL. Seems to be updated really often.
>
> Conflicts with almost every other kernel patch, including the patches in the
> default kernel source. No-one has the skill and interest necessary to make
> it work with a default Debian kernel.
It may be the hardest thing to maintain as a Debian package, but that
is due to the fact that grsecurity does _not_ only provide access
policies, but also quite a bunch of other security improvements.
However, I use grsecurity with other (small) kernel patches without
problems.
grsecurity keeps its configuration in a single file and has the best
design IMHO: it does _not_ need another system account, but either the
configuration can be changed by putting the current root shell into
'admin mode' (by supplying a passphrase) or it cannot be changed at
all (depends on the kernel settings). So by using the latter option
after having developed a sufficient configuration, you get a rock
solid and secure system.
> > (5) LIDS - http://www.lids.org/ - Own implementation of Mandatory Access
> > Control and ACLs. Seems to be around for long and is quite easy to
> > implement.
>
> This isn't updated particularly often, and doesn't seem to offer so much. If
> they had updated it more often it might have got into 2.6...
I agree. LIDS was the first thing I tried out years ago, but I dropped
it in favor of grsecurity for the same reason (too outdated).
> [SELinux]
SELinux only uses LSM which makes it easy to port, but seems
impractical and even dangerous for real-world use [1][2]. Minor issues
that I noticed: it uses a quite complicated rule syntax and insists
(according to the docs) on using an initrd, which I don't want.
> It seems that exec-shield and SE Linux are the only kernel patches that meet
> the Debian requirements for support at this time.
But after all, this people who really have to care about crucial servers
will have to have a thorough understanding of the underlying security
architecture anyway and will (hopefully) continue to have the freedom
of choice. So IMHO the choice of a default system in Debian is not as
crucial as it may have appeared in the recent flamewars.
It is much more crucial IMHO to choose a good security architecture on
the new Debian servers to ensure that a break will not occur again.
But the particular system should be choosed by the preferences of the
respective administrators, not by the ease of maintenance of Debian
packages!
> PS You may quote me publically on this, so we can move the discussion off
> debian-private.
... which I did :-)
Have a nice day everybody!
Martin
[1] http://www.rsbac.org/lsm.htm
[2] http://www.grsecurity.net/lsm.php
--
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
Attachment:
signature.asc
Description: Digital signature