Re: Specifications (the beginning)

From: Crispin Cowan (crispinat_private)
Date: Sat Apr 14 2001 - 15:57:15 PDT

  • Next message: Philippe Biondi: "Re: Specifications (the beginning)"

    Philippe Biondi wrote:
    
    > I just misinterpreted the name of the list. I dislike the presence of the
    > word "module" in it :)
    
    "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.
    
    
    > > A much more dicy question is the interface between security modules that
    > > expect AC metadata to be stored in the file system, and file systems that
    > > support extended attributes (e.g. can store an access control list associated
    > > with a file).  We don't want the security module interface to only work with
    > > exotic file systems, but we also don't want the security module interface to
    > > preclude using the security-enhancing features of exotic file systems.
    > That is the point : where is stored a rule like "httpd can't read the
    > logs" when the computer is off ?
    
    You got it; that's the question.  The answer is is (drumroll please) "Delegate to
    the modules" :-)  I.e. each module has to come up with its own solution.  There
    are two basic kinds of answers:
    
       * 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.
            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.
            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.
            o Adding a single system call for "read your conf file now" would be one
              way.  The system call could have arguments that specify things like the
              secuity identity of the requestor (other than UID, PID, etc.) and
              perhaps cryptographic credentials.
       * Depend on extended attributes:
            o Traditional MAC and ACL systems do this.  It requires that the file
              system support extended attributes, so you can attach stuff like the
              list of security IDs that may access a file to the file.
            o LSM must enable the use of extended attributes, but must not require
              extended attributes to work.  This is because the particular extended
              attributes that each file system supports is not standardized, so if we
              mandate one, we lock ourselves in to a particular file system, which is
              a disaster.
            o To achieve this, we need only ensure that whatever funky extended
              attribute manipulation functions come with each file system are exported
              to the LSM interface.  If that is already the case, then we just have to
              avoid breaking it.
    
    > > > * We need to place this call to this interface wherever it is needed.
    > > >   Lots of syscalls, VFS calls, socket calls, capable calls ...
    > > >   Part of this work should be a way to "prove" that nothing has been
    > > >   forgotten.
    > >
    > > Impossible.  You end up exporting the entire kernel.  Better to add exported
    > > things to the interface when a module comes along that needs it.
    > No exportation is needed : I'm speaking of a function that is part of the
    > kernel itself, that will be the hook at these many places in the kernel,
    > and that will call appropriate functions of a security policy module for
    > it to make the decision. This module would have registered itself before,
    > in its init function, with a security_module_register() function, which is
    > the only to be exported. Am I clearer this time ? (I hope!)
    
    Yes, you're clear.  Apparently I was not.  My claim is that it is impossible to
    prove that nothing has been forgotten.  In fact, I argue that it is not even
    desirable to hook everything conceivable.  Instead, we should hook only what is
    necessary to support modules that are actually contenders to use the LSM.  If no
    one is going to use some particular hook, then we should leave it out until such
    time as someone makes a REALLY strong case to add it.
    
    
    > > > * We need a mechanism to recognize a process to assign to it its AC data
    > > >   from the global set of AC data.
    > >
    > > Hook exec() and fork(), and let the module decide whether the newborn is
    > > something that needs policies applied to it.  The "recognition" is itself a
    > > policy that should be delegated to the modules.
    >
    > Yes, but what will the recognition rely on ? Path names ? device/inode
    > numbers ? fingerprints ?
    > - fingerprints can't identify changing files (log files, etc.)
    > - pathnames are easily fooled and do not target precisely an object
    > - device/inode numbers identify very well an object but happen to
    >   evolve through time (log file rotated, etc.)
    >
    > I think that, even with its drawback, the third is the more secure, and
    > the one that make most sense. And it happens to work not so bad.
    
    And the LSM interface should not be making such decisions for LSM modules.  We
    should make available the information needed to use each of the above features,
    and let each module use its own preferred method.  Immunix's SubDomain module uses
    absolute path names (dentries), and CryptoMark enforces fingerprints.  Thus
    SubDomain needs access to the dentry of a file, and CryptoMark needs access to the
    code space of a file that is about to be exec'd.  Other modules may need different
    information, and LSM should provide it to them.
    
    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 : Sat Apr 14 2001 - 16:00:31 PDT