Re: 2001_05_09 patch against 2.4.4

From: jmjonesat_private
Date: Thu May 10 2001 - 15:12:52 PDT

  • Next message: jmjonesat_private: "Re: 2001_05_09 patch against 2.4.4"

    |>------------------------------------------------------
    ||  J. MELVIN JONES            jmjonesat_private 
    |>------------------------------------------------------
    ||  Microcomputer Systems Consultant  
    ||  Software Developer
    ||  Web Site Design, Hosting, and Administration
    ||  Network and Systems Administration
    |>------------------------------------------------------
    ||  http://www.jmjones.com/
    |>------------------------------------------------------
    
    On Thu, 10 May 2001, Chris Evans wrote:
    
    > 
    > On Wed, 9 May 2001, Chris Wright wrote:
    > 
    > > Latest lsm patch is available.
    > >     http://lsm.immunix.org/patches/lsm-2001_05_09-2.4.4.patch.gz
    > 
    > Found the time for a quick look at "security.h" within this patch.
    > Comments follow.
    > 
    > 1) I didn't see any explict hook for file opening. I see
    > file_ops->alloc_security, but that seems to be something else. (also it
    > does not allow a security module to return other than EACCES. For
    > prevention of covert channels, you might want to return ENOENT even if
    > the file exists)
    > 
    > 2) I see, currently, that syscalls are not hooked in a generic manner.
    > >From exceptionally brief scanning of the archives, this seems to be a
    > debated point.
    > Are there plans to hook syscalls? If not, I can make a very strong
    > argument to do so. Let me know if you want to hear it.
    > 
    > 3) There's a problem brewing with regards lack of central control points
    > for logically equivalent operations.
    > For example, in file_security_ops, I see separate hooks for mmap, read,
    > write, readv, writev. But, logically, mmap(..., PROT_WRITE,
    > MAP_SHARED, ...) is equivalent to write().
    > Lack of central control may result in a module blocking access to some
    > operation, but leave a "backdoor" where the same operation is let through
    > by a different syscall sequence to achieve the same effect.
    > 
    > 
    > Cheers
    > Chris
    > 
    > 
    > _______________________________________________
    > linux-security-module mailing list
    > linux-security-moduleat_private
    > http://mail.wirex.com/mailman/listinfo/linux-security-module
    > 
    
    
    _______________________________________________
    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 : Thu May 10 2001 - 15:14:47 PDT