All of lore.kernel.org
 help / color / mirror / Atom feed
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 15:41:40 +0000	[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

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2017-09-08 15:41 UTC|newest]

Thread overview: 19+ 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 21:14 ` Eric Biggers
2017-08-16 21:14 ` Eric Biggers
     [not found] ` <20170816211403.121920-1-ebiggers3-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-08-16 22:01   ` Tyler Hicks
2017-08-16 22:01     ` Tyler Hicks
2017-08-16 22:01     ` Tyler Hicks
2017-08-16 22:08   ` Joe Richey
2017-08-16 22:08     ` Joe Richey
2017-08-16 22:08     ` Joe Richey
2017-09-05  9:54   ` David Howells
2017-09-05  9:54     ` David Howells
2017-09-05  9:54     ` David Howells
     [not found]     ` <13221.1504605295-S6HVgzuS8uM4Awkfq6JHfwNdhmdF6hFW@public.gmane.org>
2017-09-05 18:32       ` Eric Biggers
2017-09-05 18:32         ` Eric Biggers
2017-09-05 18:32         ` Eric Biggers
2017-09-08 15:41         ` David Howells [this message]
2017-09-08 15:41           ` David Howells
2017-09-17  7:25           ` Eric Biggers
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 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.