All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Eric Biggers <ebiggers@google.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>,
	Richard Weinberger <richard@nod.at>,
	Theodore Ts'o <tytso@mit.edu>,
	stable@vger.kernel.org
Subject: Re: [PATCH] KEYS: make keyctl_invalidate() also require Setattr permission
Date: Mon, 03 Apr 2017 09:20:29 +0100	[thread overview]
Message-ID: <10049.1491207629@warthog.procyon.org.uk> (raw)
In-Reply-To: <20170329220101.26067-1-ebiggers@google.com>

Eric Biggers <ebiggers@google.com> wrote:

> Currently, a process only needs Search permission on a key to invalidate
> it with keyctl_invalidate(), which has an effect similar to unlinking it
> from all keyrings.  Unfortunately, this significantly compromises the
> keys permission system because as a result, there is no way to grant
> read-only access to keys without also granting de-facto "delete" access.
> Even worse, processes may invalidate entire _keyrings_, given only
> permission to "search" them.
> 
> Key invalidation seems to have intended for cases where keyrings are
> used as caches, and keys can be re-requested at any time by an upcall to
> /sbin/request-key.  However, keyrings are not always used in this way.
> For example, users of ext4, f2fs, and ubifs encryption may wish to grant
> many differently-privileged processes access to the same keys, set up in
> a shared keyring ahead of time.  Permitting everyone to invalidate keys
> in this scenario enables a trivial denial-of-service.  And even users of
> keyrings as "just caches" may wish to restrict invalidation because it
> may require significant work or user interaction to regenerate keys.
> 
> This patch fixes the flaw by requiring both Search and Setattr
> permission to invalidate a key rather than just Search permission.
> 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.  Continuing to require Search
> permission ensures we do not decrease the level of permissions required.

I'm not sure this is the right method either.  It might be better to allocate
one of the remaining two permissions bits for this and/or mark keys that are
invalidateable.

David

  reply	other threads:[~2017-04-03  8:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-29 22:01 [PATCH] KEYS: make keyctl_invalidate() also require Setattr permission Eric Biggers
2017-03-29 22:01 ` Eric Biggers
2017-04-03  8:20 ` David Howells [this message]
2017-04-04 18:44   ` Eric Biggers
2017-04-04 18:44     ` Eric Biggers
2017-05-16 21:49     ` Eric Biggers
2017-05-16 21:49       ` Eric Biggers
2017-05-16 21:49       ` Eric Biggers
2017-05-31 19:19       ` Eric Biggers
2017-05-31 19:19         ` Eric Biggers
2017-05-31 19:19         ` 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=10049.1491207629@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=ebiggers@google.com \
    --cc=gwendal@chromium.org \
    --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=richard@nod.at \
    --cc=stable@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.