Re: [PATCH] extended attribute support

From: Stephen Smalley (sdsat_private)
Date: Tue Feb 05 2002 - 08:52:02 PST

  • Next message: Valdis.Kletnieksat_private: "Re: [PATCH] extended attribute support"

    On Tue, 5 Feb 2002 Valdis.Kletnieksat_private wrote:
    
    > Is there any reason to allow/support the security module editing the parameters
    > for its own purposes, or is it restricted to a "list is bad, go away" error
    > code?  I could see a case where "if the user program specified X:Z, we would
    > want to tack on a W:Y as well...". (For instance, if a program tried to
    > put a 'LABEL:ABC' on it, we might want to attach a 'DOMAIN:XYZ' or edit
    > ABC into a value easier for us to deal with....)
    
    A security module can mutate parameters if they are passed by reference
    (as in this case), but I wouldn't generally recommend it to security
    module writers.  However, the setxattr interface seems to only support
    setting a single (name,value) pair at a time, so you cannot simply add a
    new (name,value) pair by mutating the parameters.  The security module
    would have to call the setxattr inode operation itself with its desired
    (name,value) pair if you wanted to do this.
    
    > The alternative is that the security module then gets to keep its *own*
    > database of "files which have X:Z specified, and what values of W we've
    > attached to each one".  Quite a duplication of effort, especially when
    > the kernel already *has* support for storing what we want, and looking it
    > up ourselves may be expensive (possibly involving a call out to a userspace
    > process to do a database lookup, etc etc).
    
    I don't follow this.  A security module, like any other kernel module, can
    directly call the *xattr inode operations if it wants to use extended
    attributes.  Of course, that requires that the underlying filesystem type
    actually supports extended attributes, and I don't see any such
    filesystems in the mainstream kernel yet.  Hence, for the present,
    security modules with persistent attributes are likely to continue using
    label mapping files as in SELinux.  This doesn't require any userspace
    upcall.
    
    My point about the 'value' parameter was that the security module will
    want to know the 'value' in certain cases, e.g. when the 'name' is an
    attribute that is managed by the security module or is a well-defined
    attribute that is security-relevant.  Hence, the setxattr hook needs to
    pass it to the security module.
    
    --
    Stephen D. Smalley, NAI Labs
    ssmalleyat_private
    
    
    
    _______________________________________________
    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 : Tue Feb 05 2002 - 08:54:17 PST