Re: Security patches
On Sun, 30 Nov 2003 22:33, Martin Pitt <martin@piware.de> wrote:
> On 2003-11-29 21:08 +1100, Russell Coker wrote:
> > 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.
>
> If using a Debian-patched kernel is a requirement then I guess that
> there is not much one can do about that. (That's why I voted for
> having clean upstream kernel sources in Debian and providing Debian
> patch packages separately; but that has already been discussed without
> much of an outcome...)
I don't have any strong feelings about whether we should use a kernel.org
kernel or a Debian kernel for desktop use. But as the decision has been made
to go with a Debian kernel we should stick with that.
As a separate issue neither the stock 2.4.x kernel nor the Debian kernel works
well for the enterprise. It's on my to-do list to put a Red Hat kernel patch
in Debian...
> > > 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?
>
> Yes, of course. In my current ACL setting, _nothing_ (but login and
> getty) is allowed to access /dev/vc/*; with ptys, a similar approach
> would be do disallow access to /dev/pts/* in general and only allow it
> to ssh (I don't use incoming ssh on my box, so I did not test this).
Disallowing access to /dev/pts will not work, it will break "script",
"screen", cyclades-serial-client, wall, some implementations of talk, and
probably lots of other things.
With SE Linux the access is determined by the type label on the object (file,
directory, pipe, socket, or device node). When you change to an
administrative role via the "newrole" command it relabels the controlling tty
to prevent such access.
What you say seems to indicate that grsec does not prevent another root user
from taking over the session after it's been put in "admin mode" (or if it
does prevent such actions it does so by reducing the functionality of the
system).
> That's why I wrote "it seems" and not "it is so". :-) However, the
> arguments sound quite strong and I know a lot of people that share the
> negative attitude against LSM. This does not mean that I claim to have
> better understanding of security than Linux or the NSA; because I
> don't, I just have to consider the opinions of other people.
Sure you can consider their opinions. Also consider that they are somewhat
unhappy at having their code left out when SE Linux was put into Linus'
source tree.
LSM was not invented by the SE Linux people, it was requested by Linus as a
way of enabling the integration of multiple security systems into the kernel.
It's a pity that the developers of other security systems didn't get
involved, it would be good to have a choice of LIDS, HP's system, DTE, and
others in the standard kernel.
The claims of "porting to LSM from our current approach takes time and effort"
could have been made by SE Linux developers. However instead of complaining
they re-implemented SE Linux twice over the course of LSM development (the
first version of LSM was rejected because it had a multiplex system call
similar to socketcall() but worse). I think that the result is worth the
effort.
PS I have a SE Linux play machine online for everyone to try out. You can
login as root and see how SE Linux protects the system. There is an IRC
channel dedicated to supporting it. See the URL in my .sig.
--
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: