Re: Specifications (the beginning)

From: Chris Wright (chrisat_private)
Date: Sat Apr 14 2001 - 18:20:28 PDT

  • Next message: Tim lawless: "Re: Specifications (the beginning)"

    * Philippe Biondi (philippe.biondi@enst-bretagne.fr) wrote:
    > On Sat, 14 Apr 2001, Crispin Cowan wrote:
    > 
    > > 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.
    > 
    > I agree if module means modular and not LKM. 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.
    
    We are after a common framework resident in the kernel that gives all
    the hooks necessary to implement a security policy in a linux kernel
    module.  Then everybody can go off and implement their own security
    module conforming to the common interface.
    
    > > > > 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.
    > LIDS does it too (/etc/lids)
    > >         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.
    
    It's not the opening or reading of the file that is hard.  It is the
    fact that you have to parse all the data to populate the module specific
    data structures.  This is not work for the kernel (what else can the
    kernel do while it is doing this kind of user space work?). As Greg 
    mentioned, this is a good job for a user space tool.
    
    > >         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.
    
    I agree many modules will need information that resides in a config
    file.  But they could just as easily let a user space app read/parse and
    pass to kernel "pre-packaged" data.
    
    > >         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.
    > Can these fs work without patching the VFS layer ?
    > 
    > 
    > Anyway, I think we can't go further without having agreed which approach
    > we'll have to follow :
    > 
    > May the semantic carried by the hook stay the same, and the question asked
    > will be like :
    >  "Can 'current' exec <syscall> with <parameters>"
    > 
    > May the semantic be enriched with :
    >  "Can 'current' do <type-of-action> with <object(s)>"
    
    This _is_ what I am proposing.  I tried to break things down into objects
    and ask, "what do we need to protect in this object?"  It is a _very_
    rough sketch, and needs a lot of work, but I think we are looking for
    the same thing.
    
    > (as it is already done. For example :
    > static int open_port(struct inode * inode, struct file * filp)
    > {
    >         return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
    > }
    > 
    > We don't ask wether current can open /dev/(mem|kmem|port) but we add a
    > semantic layer, aliasing this to the need to have CAP_SYS_RAWIO. The
    > information is richer.)
    
    Yes, I agree the information is richer, and we still need open ;-)
    
    > The first solution seems more powerful at first sight but will become too
    > heavy to manage and to use because it is raw information that we try to
    > transmit, IMHO.
    
    I agree if the interface is too cumbersome it won't be useful.  This is
    why we are having this discussion ;-)
    
    -chris
    
    _______________________________________________
    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 - 18:27:58 PDT