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

Re: Security patches

On Sat, 29 Nov 2003 20:05, Martin Pitt <martin@piware.de> wrote:
> > 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.

It's not a question of how difficult it is to get the grsec patch to apply and 
work correctly on a Debian kernel.  It's a question of whether anyone is 
prepared to do it.  From the readme in the latest package:
# The grsecurity patch will *not* apply to Debian kernels following (and
# including) 2.4.20. If you want to build a grsecurity-enabled kernel with
# a version higher than or equal to 2.4.20, you should use a vanilla kernel
# source tree from one of the kernel.org mirrors.

As we want to use Debian kernels on Debian servers this precludes grsec at 
this time.  If grsec could be ported to work with the Debian kernels then 
that would be great, but it doesn't look like it will happen any time soon.

Incidentally SE Linux will be in the standard 2.6.0 Debian kernel source due 
to it's being in Linus' tree.

> 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

When the current root shell gets "admin mode" are other root processes 
prevented from reading/writing it's pty?

> SELinux only uses LSM which makes it easy to port, but seems
> impractical and even dangerous for real-world use [1][2]. Minor issues

[1] and [2] are matters of opinion.  The opinion of Linus, most other kernel 
developers, NSA people, etc is different.

Anyone is free to believe that they know security better than the NSA people 
and that they have better ideas for Linux kernel coding than Linus.  But they 
are not going to convince me in a hurry.

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

The initrd was only a suggested approach, and we have changed that for the 
next release.  The new plan is to have a modified version of init load the 
policy so there is no need for an initrd.

Incidentally I have some SE Linux systems which are incapable of using an 

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

Fair comment.  However the easiest options to maintain are the ones supported 
by Debian.  The admin team are very professional so I expect that if they 
decided to use something that was not in Debian then they would package it as 
a first step.  If packaging it was to take more time than they have available 
then it would probably preclude that choice.

http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

Reply to: