Re: [PATCH] remove sys_security

Russell Coker (russell@coker.com.au)
Fri, 18 Oct 2002 18:54:36 +0200


On Fri, 18 Oct 2002 18:33, Christoph Hellwig wrote:
> On Fri, Oct 18, 2002 at 06:30:28PM +0200, Russell Coker wrote:
> > So how does it harm the mainline kernel to have a system call reserved
> > for LSM and then not allow anything in the mainline kernel that uses it?
> > Then we can deploy modules using the current LSM design without harming
> > the mainline kernel.
>
> IT adds infrastructure to implement syscalls without peer review.

It is no easier to add syscalls without peer revies in the LSM model than it
is to add them directly. LSM merely avoids the risk of syscall conflict.

Adding syscalls without review starting at a number 1000 greater than the
current highest syscall should remove the risk of number conflict to merely a
risk of patch conflict.

Removing the LSM syscall does not remove this problem.

> > The only code that we really want to see in the mainline kernel is the
> > hooks for permission checks. Personally I would not mind if no security
> > module ever gets included in Linus' source tree.
>
> And exactly these hooks harm. They are all over the place, have
> performance and code size impact and mess up readability. Why can't you
> just maintain an external patch like i.e. mosix folks that nead similar
> deep changes?

One problem with maintaining an external patch that makes lots of deep changes
is that any patch of note will conflict with it. For most people who use
such patches that's a huge problem. I'm not a great kernel coder, so most of
the kernel coding that I do is involved with resolving such patches not
actually doing anything interesting. I'd prefer to be able to spend that
time on other tasks, which would include working on some of the issues with
coreutils we discussed.

If we remove make-work tasks from other programmers (such as repeated work to
keep a patch up to date and in-sync with other patches) then they can spend
their time productively on other tasks.

Another issue with LSM is that it's not as easy to test as Mosix. With Mosix
you can test that everything works, although these tests may not be easy
(Mosix is complex) they can give a satisfactory result. For security you
can't test it in an authoritative fashion, if a certain parameter to a
syscall results in a permission check being skipped you can't determine this
by testing. Part of the solution to this is to have the LSM code in the
mainline kernel so we are all working on the same version. Another part is
the ongoing research that IBM people are performing on validating kernel
hooks.

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

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/