From: ebiggers3@gmail.com (Eric Biggers)
To: linux-security-module@vger.kernel.org
Subject: [RFC][PATCH 00/15] KEYS: Fixes
Date: Mon, 16 Oct 2017 11:31:41 -0700 [thread overview]
Message-ID: <20171016183141.GD121701@gmail.com> (raw)
In-Reply-To: <2176.1507909168@warthog.procyon.org.uk>
On Fri, Oct 13, 2017 at 04:39:28PM +0100, David Howells wrote:
> diff --git a/security/keys/gc.c b/security/keys/gc.c
> index 87cb260e4890..e7aeecbf7f19 100644
> --- a/security/keys/gc.c
> +++ b/security/keys/gc.c
> @@ -129,14 +129,15 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
> while (!list_empty(keys)) {
> struct key *key =
> list_entry(keys->next, struct key, graveyard_link);
> + short state = key->state;
> +
> list_del(&key->graveyard_link);
>
> kdebug("- %u", key->serial);
> key_check(key);
>
> /* Throw away the key data if the key is instantiated */
> - if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags) &&
> - !test_bit(KEY_FLAG_NEGATIVE, &key->flags) &&
> + if (state == KEY_IS_INSTANTIATED &&
> key->type->destroy)
> key->type->destroy(key);
Nit: put the two checks on the same line.
>
> @@ -151,7 +152,7 @@ static noinline void key_gc_unused_keys(struct list_head *keys)
> }
>
> atomic_dec(&key->user->nkeys);
> - if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
> + if (state == KEY_IS_INSTANTIATED)
> atomic_dec(&key->user->nikeys);
This changes the behavior. Previously ->nikeys counted both negatively and
positively instantiated keys, while this change implies that it now will only
count positively instantiated keys. I think you meant 'state !=
KEY_IS_UNINSTANTIATED'? Renaming KEY_IS_INSTANTIATED to KEY_IS_POSITIVE or
KEY_IS_POSITIVELY_INSTANTIATED also might help reduce this confusion.
> @@ -901,7 +900,7 @@ long keyctl_chown_key(key_serial_t id, uid_t user, gid_t group)
> atomic_dec(&key->user->nkeys);
> atomic_inc(&newowner->nkeys);
>
> - if (test_bit(KEY_FLAG_INSTANTIATED, &key->flags)) {
> + if (key->state == KEY_IS_INSTANTIATED) {
> atomic_dec(&key->user->nikeys);
> atomic_inc(&newowner->nikeys);
> }
Same problem: ->nikeys was previously counting negatively instantiated keys too.
Now it isn't. Shouldn't it test 'key->state != KEY_IS_UNINSTANTIATED'?
> diff --git a/security/keys/proc.c b/security/keys/proc.c
> index de834309d100..9510822c4d96 100644
> --- a/security/keys/proc.c
> +++ b/security/keys/proc.c
> @@ -182,6 +182,7 @@ static int proc_keys_show(struct seq_file *m, void *v)
> unsigned long timo;
> key_ref_t key_ref, skey_ref;
> char xbuf[16];
> + short state;
> int rc;
>
> struct keyring_search_context ctx = {
> @@ -236,17 +237,19 @@ static int proc_keys_show(struct seq_file *m, void *v)
> sprintf(xbuf, "%luw", timo / (60*60*24*7));
> }
>
> + state = key_read_state(key);
> +
> #define showflag(KEY, LETTER, FLAG) \
> (test_bit(FLAG, &(KEY)->flags) ? LETTER : '-')
>
> seq_printf(m, "%08x %c%c%c%c%c%c%c %5d %4s %08x %5d %5d %-9.9s ",
> key->serial,
> - showflag(key, 'I', KEY_FLAG_INSTANTIATED),
> + state == KEY_IS_INSTANTIATED ? 'I' : '-',
Similar problem. Previously 'I' was shown for negatively instantiated keys; now
it's not. Shouldn't it test 'state != KEY_IS_UNINSTANTIATED'?
> diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
> index 293d3598153b..5a8b985d1d5f 100644
> --- a/security/keys/process_keys.c
> +++ b/security/keys/process_keys.c
> @@ -729,8 +729,7 @@ key_ref_t lookup_user_key(key_serial_t id, unsigned long lflags,
> }
>
> ret = -EIO;
> - if (!(lflags & KEY_LOOKUP_PARTIAL) &&
> - !test_bit(KEY_FLAG_INSTANTIATED, &key->flags))
> + if (!(lflags & KEY_LOOKUP_PARTIAL) && !key_is_instantiated(key))
> goto invalid_key;
Similar problem again. Previously this allowed negatively instantiated keys
through whereas now it only allows positively instantiated keys. Is that
intentional?
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-10-16 18:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-12 16:17 [RFC][PATCH 00/15] KEYS: Fixes David Howells
2017-10-12 16:26 ` David Howells
2017-10-12 18:56 ` Eric Biggers
2017-10-13 15:39 ` David Howells
2017-10-16 18:31 ` Eric Biggers [this message]
2017-10-16 22:09 ` David Howells
2017-10-16 22:27 ` David Howells
2017-10-17 17:52 ` Eric Biggers
-- strict thread matches above, loose matches on Subject: below --
2017-10-12 20:15 David Howells
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=20171016183141.GD121701@gmail.com \
--to=ebiggers3@gmail.com \
--cc=linux-security-module@vger.kernel.org \
/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).