lkml.org 
[lkml]   [2005]   [Oct]   [6]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    FromDavid Howells <>
    SubjectRe: [Keyrings] [PATCH] Keys: Add LSM hooks for key management
    DateThu, 06 Oct 2005 16:11:34 +0100
    James Morris <jmorris@namei.org> wrote:
    
    > What about a per process /proc/pid/keys, which contains keyrings and keys, 
    > which can be opened, closed, use xattrs for any special access control 
    > etc. ?
    
    Not a good idea; especially not in /proc. Why are people fixated on using the
    VFS interface when it doesn't fit? Making things into filesystems isn't
    necessarily a good thing.
    
    However, /proc/pid/xxx files for the ID of each keyring would be a good idea;
    I did have a patch to do that once, but it seems have got lost.
    
    > > Should I expand the permissions mask to include a setattr?
    > 
    > Possibly for setperm and chown.
    
    For setperm?
    
    > > > All users of key_permission() need to propagate the error code from the 
    > > > LSM back to the user.
    > > 
    > > Really? Why?
    > 
    > Because the LSM has final say on the error code returned to the caller.  
    > If the LSM runs out of memory, for example, it's silly to return -EACCES.
    > 
    > > Note that the fact that key_permission() fails for a key is sometimes
    > > ignored, such as when I'm doing a search and one potentially matching key
    > > fails, but a subsequent matching key passes.
    > 
    > Ok, that sounds like an internal issue to be resolved, ensuring that if 
    > you are returning to the caller, the LSM's error code is returned.
    
    But which LSM error code?
    
    Let me explain what I mean:
    
     (1) When the key management code searches for a key (keyring_search_aux) it
         firstly calls key_permission(SEARCH) on the keyring it's starting with,
         if this denies permission, it doesn't search further.
    
     (2) It considers all the non-keyring keys within that keyring and, if any key
         matches the criteria specified, calls key_permission(SEARCH) on it to see
         if the key is allowed to be found. If it is, that key is returned; if
         not, the search continues, and the error code is retained if of higher
         priority than the one currently set.
    
     (3) It then considers all the keyring-type keys in the keyring it's currently
         searching. It calls key_permission(SEARCH) on each keyring, and if this
         grants permission, it recurses, executing steps (2) and (3) on that
         keyring.
    
    The process stops immediately a valid key is found with permission granted to
    use it. Any error from a previous match attempt is discarded and the key is
    returned.
    
    When search_process_keyrings() is invoked, it performs the following searches
    until one succeeds:
    
     (1) If extant, the process's thread keyring is searched.
    
     (2) If extant, the process's process keyring is searched.
    
     (3) The process's session keyring is searched.
    
     (4) If the process has a request_key() authorisation key in its session
         keyring then:
    
         (a) If extant, the calling process's thread keyring is searched.
    
         (b) If extant, the calling process's process keyring is searched.
    
         (c) The calling process's session keyring is searched.
    
    The moment one succeeds, all pending errors are discarded and the found key is
    returned.
    
    Only if all these fail does the whole thing fail with the highest priority
    error. Note that several errors may have come from LSM.
    
    The error priority should be:
    
    	EKEYREVOKED > EKEYEXPIRED > ENOKEY
    EACCES/EPERM should only really be returned on a direct keyring search where
    the basal keyring doesn't have Search permission.
    
    The fact that I couldn't find a key because I didn't have permission to find
    it probably shouldn't cause an immediate abort of the search with an error, or
    any error other than ENOKEY/EKEYREVOKED/EKEYEXPIRED, unless I'm not permitted
    to request a new key.
    
    David
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2005-10-06 15:14    [from the cache]
    ©2003-2008