Thread (7 messages) 7 messages, 4 authors, 2017-09-17

Re: [PATCH v2] KEYS: make keyctl_invalidate() also require Setattr permission

From: Eric Biggers <hidden>
Date: 2017-09-05 18:32:53
Also in: keyrings, linux-cifs, linux-fscrypt, linux-nfs, stable

Hi David,

On Tue, Sep 05, 2017 at 10:54:55AM +0100, David Howells wrote:
Eric Biggers [off-list ref] wrote:
quoted
This patch fixes the flaw by requiring both Search and Setattr permission to
invalidate a key rather than just Search permission.
I'm not sure I agree.  The problem is that you then have to grant someone
Setattr permission for them to be able to do this, which then opens up a whole
host of other things they can also do.
True, but Setattr permission has already been overloaded to allow several
different types of modifications, and it makes *much* more sense than Search
permission which should not allow any modifications.  And in practice I expect
people care more about whether modifications are permitted or not, than the
details of the finer-grained permissions.
quoted
Requiring Setattr permission is appropriate because Setattr permission also
allows revoking (via keyctl_revoke()) or expiring (via keyctl_set_timeout())
the key, which also make the key inaccessible regardless of how many
keyrings it is in.
Note that setting the expiry time is not really equivalent to revokation in
this regard as setting the expiry time is something you do when setting up a
key, whereas revokation is something you do later to kill a key off.
Sort of, but actually keyctl_set_timeout() can be called at any time, and the
timeout can be set to as little as 1 second.  So I don't see how keyctl_revoke()
is that much different, fundamentally.
How about another solution:

 (1) I add a flag to a key to say that it can be invalidated and a keyctl to
     change that flag.
And who would have permission to change that flag?  It seems to be the same
problem again.
 (2) I add a new key type op called ->allow_invalidation() that allows key
     types to govern separately who is allowed to invalidate keys of that
     type.

     So, for instance, DNS record invalidation would require CAP_NET_ADMIN.
What would the behavior be if ->allow_invalidation() was not supplied?  In other
words, would the purpose of this be to lock down invalidation of dns_resolver
keys, or to restrict invalidation to *only* dns_resolver keys?
 (3) Allow keyrings to be cleared by users who don't have Write permission but
     do have other permission, such as CAP_NET_ADMIN.  This would need to be
     granted on a per-keyring basis.
Granted by who, and how?  And do you mean keyctl_clear(), or
keyctl_invalidate()?

- Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help