Re: Specifications (the beginning)

From: Crispin Cowan (crispinat_private)
Date: Sun Apr 15 2001 - 00:17:22 PDT

  • Next message: Crispin Cowan: "Re: Specifications (the beginning)"

    Philippe Biondi wrote:
    
    > On Sat, 14 Apr 2001, Crispin Cowan wrote:
    > > "module" is the *most* important word in the list name.  There's lots & lots of
    > > generic security discussion forums, and even lots of linux security discussion
    > > forums.  I'm trying to chase awasy all of the discussion about the merrits of one
    > > security model over another, and concentrate on the LSM features needed to support
    > > a diverse set of security modules.
    >
    > I agree if module means modular and not LKM.
    
    Yes, it means LKM.  We are not talking about turning Linux into a microkernel here,
    just adding sufficient functionality to the LKM interface to enable security LKMs to
    exist (which I've been denoting LSM for "Linux Security Module", hence the list name).
    
    
    > Wanting to make a modular
    > implementation is important and means that we can get security policies
    > out of the kernel, in LKMs. Wanting to make a LKM is nonsense, IMHO.
    
    I don't really understand what you're saying here.  You seem to be contradicting
    yourself, but mostly I'm just confused.
    
    
    > >    * Put it in a .conf file:
    > >         o Janus and SubDomain do this.  Subdomain by default reads that kind of
    > >           information from the files found in /etc/subdomain.d/* .  Janus does
    > >           something similar, but I'm not up on the particulars.  I suspect LIDS
    > >           does this, but I don't know.
    > LIDS does it too (/etc/lids)
    
    Makes sense.
    
    
    > >         o Supporting "read a conf file" requires that the module have some way to
    > >           read a file from within the kernel, which is actually rather hard.
    > >           SubDomain kludges this with a funny ioctl, but it's gross.
    > It's quite easy !? with things like filp_open() (which are already
    > exported). Maybe I missed something.
    
    As Greg helpfully reminded me, there are problems asking the kernel to read ASCII from
    user space files:
    
       * kernel blocking on a disk I/O
       * disk read errors
       * parsing errors
       * etc.
    
    So it's best to have a program push the file into the kernel, rather than let the
    kernel read it direct from a file.  Then the program can fail gracefully, rather than
    the kernel taking the hit when something goes wrong.
    
    
    > >         o There are also security issues involved in who may cause the conf file
    > >           to be read, because the attacker may hack the file and induce a reload.
    > >           Thus the security module itself must have control over who may cause a
    > >           reload.
    > >         o I suggest that we add an explicit feature for LSM modules to read
    > >           configuration files.  The stimulus to read the file would come from
    > >           user-land, but must be viewed as a request, not a commandment.  The
    > >           request must come with a bunch of authenication data, so that the LSM
    > >           module can properly consider the request.
    > If the config file is agreed to be the best solution for storing rules,
    > reading a config file must be a service provided, as lots of models will
    > need it.
    
    It is not "aggreed to be the best solution".  It is agreed to be a commonly-used
    approach which needs to be supported.  It is important that the LSM interface should
    *not* impose opinions as to what is the best solution, where ever possible.
    
    
    > Can these fs work without patching the VFS layer ?
    
    By definition, yes:  ext2 supports a form of extended attributes.  You access those
    attributes with the chattr and lsatter commands.
    http://www.securityfocus.com/focus/linux/articles/ext2attr.html
    
    However, some other extended attributes projects apparently require patching the VFS
    layer  http://lwn.net/2000/1026/a/extended-attributes.php3
    
    I agree with Greg: we don't want to get into a can of worms in the VFS layer.  The
    trick is to figure out how to allow modules to use extended attributes without getting
    entangled.
    
    Crispin
    
    --
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com
    Security Hardened Linux Distribution:       http://immunix.org
    
    
    
    
    _______________________________________________
    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 : Sun Apr 15 2001 - 00:20:11 PDT