Re: Possible system call interface for LSM

From: jmjonesat_private
Date: Fri Aug 10 2001 - 19:00:10 PDT

  • Next message: David Wagner: "Re: Possible system call interface for LSM"

    On Fri, 10 Aug 2001, Crispin Cowan wrote:
    
    > My main axe to grind here was that it should be a syscall, so I've been
    > quite through the rest of the debate, but thought I'd chip in here.
    > 
    [...]
    > 
    > I believe that the argumenthere is that the compute cost of an extra
    > parameter is paid by all modules on every call to the LSM syscall, vs. a
    > one-time cost of accessing a pseudo-file to identify a module.  The file
    > access is slower, but occurs much less often, off the critical path.
    
    Relegate this to testing?  By the time it's tested, it'll be so deep in
    LSM that it will be a whole NEW argument to get it out.  I have been
    burned by this idea before and would rather not "sit tight" on it again.
    (just me.)
    
    I agree with you (ignoring the race problems, which I think are
    insignificant), but am worried about saying "let us go this way and we can
    go back later."  I haven't seen a good example of this ever being true.  I
    don't have access to the bitkeeper tree (no whine intended) but the
    patches seem to be "first in, permanent"
    
    > 
    > 
    > > * And how much bloat is creating a single /proc entry to let your
    > > * userspace programs know that your module is loaded?
    > >
    > > Well, now I need /proc compiled in, that's 46k.
    > 
    > It seems legitimate that an application may want to probe for the existance
    > of a specific module.  But it also seems that not all modules will have this
    > need (e.g. SubDomain doesn't need it, because I don't care how well
    > SubDomain-enabled apps run on non-Immunix systems).  So what we need is a
    > way for applications to detect modules, such that:
    > 
    >    * the detection doesn't cost too much
    >    * modules & applications that don't care about module detection don't pay
    >      for it
    
    A simple defined syscall through our captured interface that simply
    returns a pointer to some sort of identifier object would accomplish this.
    
    Call == -1
    ...
    
    > 
    > Richard seems to feel that 46 KB of kernel space for /proc is too much to
    > pay.  That seems a tad extreme to me: 46 KB is not much space for any
    > machine bigger than a wrist watch, and for larger systems, I suggest that
    > /proc will be included most of the time anyway.  So:
    > 
    >    * Richard: what embedded applications are there that are that tight on
    >      memory, and also need B1 security? (1/2 :-)
    >    * Group: is there perhaps a cheaper way to indicate the presence of an
    >      LSM module than a /proc entry? Or is that really the Linux Way to do
    >      this, and we should stop with the fussing?
    
    STOP WITH THE FUSSING.   If we're not going to monitor EVERY syscall and
    revalidate it, there are a plethora of other means available.  If a module
    WANTS to be paranoid and validate on every call, there's an inherent means
    available.
    
    I don't want an LSM interface that breaks my module philosophy, but this
    is one that doesn't (IMHO) belong here... there are other ways to address 
    this issue.
    
    I'd rather NOT have to drop back to arguing for "tweaks" that circumvent
    the check.
    
    > > Crispin
    > 
    > --
    > Crispin Cowan, Ph.D.
    > Chief Scientist, WireX Communications, Inc. http://wirex.com
    > Security Hardened Linux Distribution:       http://immunix.org
    > Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    > 
    
    Sincerely,
    J. Melvin Jones
    
    |>------------------------------------------------------
    ||  J. MELVIN JONES            jmjonesat_private 
    |>------------------------------------------------------
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    |>------------------------------------------------------
    ||  http://www.jmjones.com/
    |>------------------------------------------------------
    
    
    
    
    _______________________________________________
    linux-security-module mailing list
    linux-security-moduleat_private
    http://mail.wirex.com/mailman/listinfo/linux-security-module
    



    This archive was generated by hypermail 2b30 : Fri Aug 10 2001 - 19:05:06 PDT