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

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

From: David Howells <dhowells@redhat.com>
Date: 2017-09-08 15:41:44
Also in: keyrings, linux-cifs, linux-fscrypt, linux-nfs, stable

Eric Biggers [off-list ref] wrote:
True, but Setattr permission has already been overloaded to allow several
different types of modifications,
Perhaps therein lies the problem.  Setattr is too overloaded and really needs
splitting along the following lines:

 (1) Security: ownership, access, security label, restrictions.

 (2) Content: alter/update, timeout.

 (3) Revocation and invalidation.

Maybe I should create some sort of ACL for keys and map setperm onto that.

I wonder if this could also intersect with user namespaces in some way so that
you can make an ACL that has users from multiple namespaces - might be tricky,
though.
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.
I disagree still.  To allow users to invalidate a key you would *also* have to
give them the ability to muck around with the permissions.
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.
The timeout is a property of the key content and revoked is one of the states
the key can be in.
quoted
 (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.
No.  Setperm would be required to change the flag, but not to apply the
invalidate operation if the flag is set.  Think of Invalidate as being a
mass-unlink operation effected by the garbage collector.

Kernel-created DNS keys, for example, don't grant Setperm to anyone.
What would the behavior be if ->allow_invalidation() was not supplied?
The obvious would be to check that you're the owner of the key.
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?
To restrict who could invalidate keys of a particular type.  Actually, it
wants to be per-key not per-key-type.  Hmmm...
Granted by who, and how?  And do you mean keyctl_clear(), or
keyctl_invalidate()?
keyctl_clear().  Empty the keyring, not render it unusable.


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