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