Re: [PATCH] remove sys_security

From: Russell Coker (russellat_private)
Date: Fri Oct 18 2002 - 09:54:36 PDT

  • Next message: Terry Bohaning: "Please Call"

    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 
    --   My NSA Security Enhanced Linux packages  Bonnie++ hard drive benchmark    Postal SMTP/POP benchmark  My home page
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Fri Oct 18 2002 - 09:56:10 PDT