[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security patches


(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

> > (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

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

> 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!


[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

Reply to: