From: David Howells <dhowells@redhat.com>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: dhowells@redhat.com, keyrings@vger.kernel.org,
linux-api@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-fscrypt@vger.kernel.org, linux-nfs@vger.kernel.org,
Gwendal Grignou <gwendal@chromium.org>,
Jaegeuk Kim <jaegeuk@kernel.org>,
Paul Crowley <paulcrowley@google.com>,
Richard Weinberger <richard@nod.at>,
Ryo Hashimoto <hashimoto@google.com>,
Tyler Hicks <tyhicks@canonical.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v2] KEYS: make keyctl_invalidate() also require Setattr permission
Date: Fri, 08 Sep 2017 16:41:40 +0100 [thread overview]
Message-ID: <610.1504885300@warthog.procyon.org.uk> (raw)
In-Reply-To: <20170905183250.GA92687@gmail.com>
Eric Biggers <ebiggers3@gmail.com> 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.
> > (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
next prev parent reply other threads:[~2017-09-08 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 21:14 [PATCH v2] KEYS: make keyctl_invalidate() also require Setattr permission Eric Biggers
2017-08-16 22:01 ` Tyler Hicks
2017-08-16 22:08 ` Joe Richey
2017-09-05 9:54 ` David Howells
2017-09-05 18:32 ` Eric Biggers
2017-09-08 15:41 ` David Howells [this message]
2017-09-17 7:25 ` Eric Biggers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=610.1504885300@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=ebiggers3@gmail.com \
--cc=gwendal@chromium.org \
--cc=hashimoto@google.com \
--cc=jaegeuk@kernel.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=paulcrowley@google.com \
--cc=richard@nod.at \
--cc=stable@vger.kernel.org \
--cc=tyhicks@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).