diff options
| author | David Howells <dhowells@redhat.com> | 2012-10-02 20:24:56 +0200 |
|---|---|---|
| committer | David Howells <dhowells@redhat.com> | 2012-10-02 20:24:56 +0200 |
| commit | 96b5c8fea6c0861621051290d705ec2e971963f1 (patch) | |
| tree | 3e3812fb8eb9590b8dca812e916d16cfd53aa862 /security/keys/key.c | |
| parent | KEYS: Make the session and process keyrings per-thread (diff) | |
| download | linux-96b5c8fea6c0861621051290d705ec2e971963f1.tar.xz linux-96b5c8fea6c0861621051290d705ec2e971963f1.zip | |
KEYS: Reduce initial permissions on keys
Reduce the initial permissions on new keys to grant the possessor everything,
view permission only to the user (so the keys can be seen in /proc/keys) and
nothing else.
This gives the creator a chance to adjust the permissions mask before other
processes can access the new key or create a link to it.
To aid with this, keyring_alloc() now takes a permission argument rather than
setting the permissions itself.
The following permissions are now set:
(1) The user and user-session keyrings grant the user that owns them full
permissions and grant a possessor everything bar SETATTR.
(2) The process and thread keyrings grant the possessor full permissions but
only grant the user VIEW. This permits the user to see them in
/proc/keys, but not to do anything with them.
(3) Anonymous session keyrings grant the possessor full permissions, but only
grant the user VIEW and READ. This means that the user can see them in
/proc/keys and can list them, but nothing else. Possibly READ shouldn't
be provided either.
(4) Named session keyrings grant everything an anonymous session keyring does,
plus they grant the user LINK permission. The whole point of named
session keyrings is that others can also subscribe to them. Possibly this
should be a separate permission to LINK.
(5) The temporary session keyring created by call_sbin_request_key() gets the
same permissions as an anonymous session keyring.
(6) Keys created by add_key() get VIEW, SEARCH, LINK and SETATTR for the
possessor, plus READ and/or WRITE if the key type supports them. The used
only gets VIEW now.
(7) Keys created by request_key() now get the same as those created by
add_key().
Reported-by: Lennart Poettering <lennart@poettering.net>
Reported-by: Stef Walter <stefw@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Diffstat (limited to 'security/keys/key.c')
| -rw-r--r-- | security/keys/key.c | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/security/keys/key.c b/security/keys/key.c index 50d96d4e06f2..bebeca3a78e4 100644 --- a/security/keys/key.c +++ b/security/keys/key.c @@ -826,13 +826,13 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref, /* if the client doesn't provide, decide on the permissions we want */ if (perm == KEY_PERM_UNDEF) { perm = KEY_POS_VIEW | KEY_POS_SEARCH | KEY_POS_LINK | KEY_POS_SETATTR; - perm |= KEY_USR_VIEW | KEY_USR_SEARCH | KEY_USR_LINK | KEY_USR_SETATTR; + perm |= KEY_USR_VIEW; if (ktype->read) - perm |= KEY_POS_READ | KEY_USR_READ; + perm |= KEY_POS_READ; if (ktype == &key_type_keyring || ktype->update) - perm |= KEY_USR_WRITE; + perm |= KEY_POS_WRITE; } /* allocate a new key */ |