2017-11-01 08:09:13 -06:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
|
2005-04-16 16:20:36 -06:00
|
|
|
/* keyctl.h: keyctl command IDs
|
|
|
|
*
|
KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments. Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist. This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
(1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
keyring by ID (ringid >= 0), then that keyring will be used.
(2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
special constants that refer to the requesting process's keyrings
(KEY_SPEC_*_KEYRING, all <= 0), then:
(a) If sys_request_key() was given a keyring to use (destringid) then the
key will be attached to that keyring.
(b) If sys_request_key() was given a NULL keyring, then the key being
instantiated will be attached to the default keyring as set by
keyctl_set_reqkey_keyring().
(3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained. This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
+-----------+ +--------------+ +--------------+
| | | | | |
| Requestor |------->| Instantiator |------->| Instantiator |
| | | | | |
+-----------+ +--------------+ +--------------+
request_key() request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch. The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator. To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
2008-11-13 16:39:14 -07:00
|
|
|
* Copyright (C) 2004, 2008 Red Hat, Inc. All Rights Reserved.
|
2005-04-16 16:20:36 -06:00
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version
|
|
|
|
* 2 of the License, or (at your option) any later version.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _LINUX_KEYCTL_H
|
|
|
|
#define _LINUX_KEYCTL_H
|
|
|
|
|
2016-04-12 12:54:58 -06:00
|
|
|
#include <linux/types.h>
|
|
|
|
|
keys: Replace uid/gid/perm permissions checking with an ACL
Replace the uid/gid/perm permissions checking on a key with an ACL to allow
the SETATTR and SEARCH permissions to be split. This will also allow a
greater range of subjects to represented.
============
WHY DO THIS?
============
The problem is that SETATTR and SEARCH cover a slew of actions, not all of
which should be grouped together.
For SETATTR, this includes actions that are about controlling access to a
key:
(1) Changing a key's ownership.
(2) Changing a key's security information.
(3) Setting a keyring's restriction.
And actions that are about managing a key's lifetime:
(4) Setting an expiry time.
(5) Revoking a key.
and (proposed) managing a key as part of a cache:
(6) Invalidating a key.
Managing a key's lifetime doesn't really have anything to do with
controlling access to that key.
Expiry time is awkward since it's more about the lifetime of the content
and so, in some ways goes better with WRITE permission. It can, however,
be set unconditionally by a process with an appropriate authorisation token
for instantiating a key, and can also be set by the key type driver when a
key is instantiated, so lumping it with the access-controlling actions is
probably okay.
As for SEARCH permission, that currently covers:
(1) Finding keys in a keyring tree during a search.
(2) Permitting keyrings to be joined.
(3) Invalidation.
But these don't really belong together either, since these actions really
need to be controlled separately.
Finally, there are number of special cases to do with granting the
administrator special rights to invalidate or clear keys that I would like
to handle with the ACL rather than key flags and special checks.
===============
WHAT IS CHANGED
===============
The SETATTR permission is split to create two new permissions:
(1) SET_SECURITY - which allows the key's owner, group and ACL to be
changed and a restriction to be placed on a keyring.
(2) REVOKE - which allows a key to be revoked.
The SEARCH permission is split to create:
(1) SEARCH - which allows a keyring to be search and a key to be found.
(2) JOIN - which allows a keyring to be joined as a session keyring.
(3) INVAL - which allows a key to be invalidated.
The WRITE permission is also split to create:
(1) WRITE - which allows a key's content to be altered and links to be
added, removed and replaced in a keyring.
(2) CLEAR - which allows a keyring to be cleared completely. This is
split out to make it possible to give just this to an administrator.
(3) REVOKE - see above.
Keys acquire ACLs which consist of a series of ACEs, and all that apply are
unioned together. An ACE specifies a subject, such as:
(*) Possessor - permitted to anyone who 'possesses' a key
(*) Owner - permitted to the key owner
(*) Group - permitted to the key group
(*) Everyone - permitted to everyone
Note that 'Other' has been replaced with 'Everyone' on the assumption that
you wouldn't grant a permit to 'Other' that you wouldn't also grant to
everyone else.
Further subjects may be made available by later patches.
The ACE also specifies a permissions mask. The set of permissions is now:
VIEW Can view the key metadata
READ Can read the key content
WRITE Can update/modify the key content
SEARCH Can find the key by searching/requesting
LINK Can make a link to the key
SET_SECURITY Can change owner, ACL, expiry
INVAL Can invalidate
REVOKE Can revoke
JOIN Can join this keyring
CLEAR Can clear this keyring
The KEYCTL_SETPERM function is then deprecated.
The KEYCTL_SET_TIMEOUT function then is permitted if SET_SECURITY is set,
or if the caller has a valid instantiation auth token.
The KEYCTL_INVALIDATE function then requires INVAL.
The KEYCTL_REVOKE function then requires REVOKE.
The KEYCTL_JOIN_SESSION_KEYRING function then requires JOIN to join an
existing keyring.
The JOIN permission is enabled by default for session keyrings and manually
created keyrings only.
======================
BACKWARD COMPATIBILITY
======================
To maintain backward compatibility, KEYCTL_SETPERM will translate the
permissions mask it is given into a new ACL for a key - unless
KEYCTL_SET_ACL has been called on that key, in which case an error will be
returned.
It will convert possessor, owner, group and other permissions into separate
ACEs, if each portion of the mask is non-zero.
SETATTR permission turns on all of INVAL, REVOKE and SET_SECURITY. WRITE
permission turns on WRITE, REVOKE and, if a keyring, CLEAR. JOIN is turned
on if a keyring is being altered.
The KEYCTL_DESCRIBE function translates the ACL back into a permissions
mask to return depending on possessor, owner, group and everyone ACEs.
It will make the following mappings:
(1) INVAL, JOIN -> SEARCH
(2) SET_SECURITY -> SETATTR
(3) REVOKE -> WRITE if SETATTR isn't already set
(4) CLEAR -> WRITE
Note that the value subsequently returned by KEYCTL_DESCRIBE may not match
the value set with KEYCTL_SETATTR.
=======
TESTING
=======
This passes the keyutils testsuite for all but a couple of tests:
(1) tests/keyctl/dh_compute/badargs: The first wrong-key-type test now
returns EOPNOTSUPP rather than ENOKEY as READ permission isn't removed
if the type doesn't have ->read(). You still can't actually read the
key.
(2) tests/keyctl/permitting/valid: The view-other-permissions test doesn't
work as Other has been replaced with Everyone in the ACL.
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-27 16:03:07 -06:00
|
|
|
/*
|
|
|
|
* Keyring permission grant definitions
|
|
|
|
*/
|
|
|
|
enum key_ace_subject_type {
|
|
|
|
KEY_ACE_SUBJ_STANDARD = 0, /* subject is one of key_ace_standard_subject */
|
|
|
|
nr__key_ace_subject_type
|
|
|
|
};
|
|
|
|
|
|
|
|
enum key_ace_standard_subject {
|
|
|
|
KEY_ACE_EVERYONE = 0, /* Everyone, including owner and group */
|
|
|
|
KEY_ACE_GROUP = 1, /* The key's group */
|
|
|
|
KEY_ACE_OWNER = 2, /* The owner of the key */
|
|
|
|
KEY_ACE_POSSESSOR = 3, /* Any process that possesses of the key */
|
|
|
|
nr__key_ace_standard_subject
|
|
|
|
};
|
|
|
|
|
|
|
|
#define KEY_ACE_VIEW 0x00000001 /* Can describe the key */
|
|
|
|
#define KEY_ACE_READ 0x00000002 /* Can read the key content */
|
|
|
|
#define KEY_ACE_WRITE 0x00000004 /* Can update/modify the key content */
|
|
|
|
#define KEY_ACE_SEARCH 0x00000008 /* Can find the key by search */
|
|
|
|
#define KEY_ACE_LINK 0x00000010 /* Can make a link to the key */
|
|
|
|
#define KEY_ACE_SET_SECURITY 0x00000020 /* Can set owner, group, ACL */
|
|
|
|
#define KEY_ACE_INVAL 0x00000040 /* Can invalidate the key */
|
|
|
|
#define KEY_ACE_REVOKE 0x00000080 /* Can revoke the key */
|
|
|
|
#define KEY_ACE_JOIN 0x00000100 /* Can join keyring */
|
|
|
|
#define KEY_ACE_CLEAR 0x00000200 /* Can clear keyring */
|
|
|
|
#define KEY_ACE__PERMS 0xffffffff
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Old-style permissions mask, deprecated in favour of ACL.
|
|
|
|
*/
|
|
|
|
#define KEY_POS_VIEW 0x01000000 /* possessor can view a key's attributes */
|
|
|
|
#define KEY_POS_READ 0x02000000 /* possessor can read key payload / view keyring */
|
|
|
|
#define KEY_POS_WRITE 0x04000000 /* possessor can update key payload / add link to keyring */
|
|
|
|
#define KEY_POS_SEARCH 0x08000000 /* possessor can find a key in search / search a keyring */
|
|
|
|
#define KEY_POS_LINK 0x10000000 /* possessor can create a link to a key/keyring */
|
|
|
|
#define KEY_POS_SETATTR 0x20000000 /* possessor can set key attributes */
|
|
|
|
#define KEY_POS_ALL 0x3f000000
|
|
|
|
|
|
|
|
#define KEY_USR_VIEW 0x00010000 /* user permissions... */
|
|
|
|
#define KEY_USR_READ 0x00020000
|
|
|
|
#define KEY_USR_WRITE 0x00040000
|
|
|
|
#define KEY_USR_SEARCH 0x00080000
|
|
|
|
#define KEY_USR_LINK 0x00100000
|
|
|
|
#define KEY_USR_SETATTR 0x00200000
|
|
|
|
#define KEY_USR_ALL 0x003f0000
|
|
|
|
|
|
|
|
#define KEY_GRP_VIEW 0x00000100 /* group permissions... */
|
|
|
|
#define KEY_GRP_READ 0x00000200
|
|
|
|
#define KEY_GRP_WRITE 0x00000400
|
|
|
|
#define KEY_GRP_SEARCH 0x00000800
|
|
|
|
#define KEY_GRP_LINK 0x00001000
|
|
|
|
#define KEY_GRP_SETATTR 0x00002000
|
|
|
|
#define KEY_GRP_ALL 0x00003f00
|
|
|
|
|
|
|
|
#define KEY_OTH_VIEW 0x00000001 /* third party permissions... */
|
|
|
|
#define KEY_OTH_READ 0x00000002
|
|
|
|
#define KEY_OTH_WRITE 0x00000004
|
|
|
|
#define KEY_OTH_SEARCH 0x00000008
|
|
|
|
#define KEY_OTH_LINK 0x00000010
|
|
|
|
#define KEY_OTH_SETATTR 0x00000020
|
|
|
|
#define KEY_OTH_ALL 0x0000003f
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* special process keyring shortcut IDs */
|
|
|
|
#define KEY_SPEC_THREAD_KEYRING -1 /* - key ID for thread-specific keyring */
|
|
|
|
#define KEY_SPEC_PROCESS_KEYRING -2 /* - key ID for process-specific keyring */
|
|
|
|
#define KEY_SPEC_SESSION_KEYRING -3 /* - key ID for session-specific keyring */
|
|
|
|
#define KEY_SPEC_USER_KEYRING -4 /* - key ID for UID-specific keyring */
|
|
|
|
#define KEY_SPEC_USER_SESSION_KEYRING -5 /* - key ID for UID-session keyring */
|
|
|
|
#define KEY_SPEC_GROUP_KEYRING -6 /* - key ID for GID-specific keyring */
|
2006-01-08 02:02:47 -07:00
|
|
|
#define KEY_SPEC_REQKEY_AUTH_KEY -7 /* - key ID for assumed request_key auth key */
|
KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments. Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist. This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
(1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
keyring by ID (ringid >= 0), then that keyring will be used.
(2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
special constants that refer to the requesting process's keyrings
(KEY_SPEC_*_KEYRING, all <= 0), then:
(a) If sys_request_key() was given a keyring to use (destringid) then the
key will be attached to that keyring.
(b) If sys_request_key() was given a NULL keyring, then the key being
instantiated will be attached to the default keyring as set by
keyctl_set_reqkey_keyring().
(3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained. This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
+-----------+ +--------------+ +--------------+
| | | | | |
| Requestor |------->| Instantiator |------->| Instantiator |
| | | | | |
+-----------+ +--------------+ +--------------+
request_key() request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch. The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator. To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
2008-11-13 16:39:14 -07:00
|
|
|
#define KEY_SPEC_REQUESTOR_KEYRING -8 /* - key ID for request_key() dest keyring */
|
2005-04-16 16:20:36 -06:00
|
|
|
|
[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
(1) There's a new special key type called ".request_key_auth".
This is an authorisation key for when one process requests a key and
another process is started to construct it. This type of key cannot be
created by the user; nor can it be requested by kernel services.
Authorisation keys hold two references:
(a) Each refers to a key being constructed. When the key being
constructed is instantiated the authorisation key is revoked,
rendering it of no further use.
(b) The "authorising process". This is either:
(i) the process that called request_key(), or:
(ii) if the process that called request_key() itself had an
authorisation key in its session keyring, then the authorising
process referred to by that authorisation key will also be
referred to by the new authorisation key.
This means that the process that initiated a chain of key requests
will authorise the lot of them, and will, by default, wind up with
the keys obtained from them in its keyrings.
(2) request_key() creates an authorisation key which is then passed to
/sbin/request-key in as part of a new session keyring.
(3) When request_key() is searching for a key to hand back to the caller, if
it comes across an authorisation key in the session keyring of the
calling process, it will also search the keyrings of the process
specified therein and it will use the specified process's credentials
(fsuid, fsgid, groups) to do that rather than the calling process's
credentials.
This allows a process started by /sbin/request-key to find keys belonging
to the authorising process.
(4) A key can be read, even if the process executing KEYCTL_READ doesn't have
direct read or search permission if that key is contained within the
keyrings of a process specified by an authorisation key found within the
calling process's session keyring, and is searchable using the
credentials of the authorising process.
This allows a process started by /sbin/request-key to read keys belonging
to the authorising process.
(5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
KEYCTL_NEGATE will specify a keyring of the authorising process, rather
than the process doing the instantiation.
(6) One of the process keyrings can be nominated as the default to which
request_key() should attach new keys if not otherwise specified. This is
done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
constants. The current setting can also be read using this call.
(7) request_key() is partially interruptible. If it is waiting for another
process to finish constructing a key, it can be interrupted. This permits
a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 23:00:56 -06:00
|
|
|
/* request-key default keyrings */
|
|
|
|
#define KEY_REQKEY_DEFL_NO_CHANGE -1
|
|
|
|
#define KEY_REQKEY_DEFL_DEFAULT 0
|
|
|
|
#define KEY_REQKEY_DEFL_THREAD_KEYRING 1
|
|
|
|
#define KEY_REQKEY_DEFL_PROCESS_KEYRING 2
|
|
|
|
#define KEY_REQKEY_DEFL_SESSION_KEYRING 3
|
|
|
|
#define KEY_REQKEY_DEFL_USER_KEYRING 4
|
|
|
|
#define KEY_REQKEY_DEFL_USER_SESSION_KEYRING 5
|
|
|
|
#define KEY_REQKEY_DEFL_GROUP_KEYRING 6
|
KEYS: Alter use of key instantiation link-to-keyring argument
Alter the use of the key instantiation and negation functions' link-to-keyring
arguments. Currently this specifies a keyring in the target process to link
the key into, creating the keyring if it doesn't exist. This, however, can be
a problem for copy-on-write credentials as it means that the instantiating
process can alter the credentials of the requesting process.
This patch alters the behaviour such that:
(1) If keyctl_instantiate_key() or keyctl_negate_key() are given a specific
keyring by ID (ringid >= 0), then that keyring will be used.
(2) If keyctl_instantiate_key() or keyctl_negate_key() are given one of the
special constants that refer to the requesting process's keyrings
(KEY_SPEC_*_KEYRING, all <= 0), then:
(a) If sys_request_key() was given a keyring to use (destringid) then the
key will be attached to that keyring.
(b) If sys_request_key() was given a NULL keyring, then the key being
instantiated will be attached to the default keyring as set by
keyctl_set_reqkey_keyring().
(3) No extra link will be made.
Decision point (1) follows current behaviour, and allows those instantiators
who've searched for a specifically named keyring in the requestor's keyring so
as to partition the keys by type to still have their named keyrings.
Decision point (2) allows the requestor to make sure that the key or keys that
get produced by request_key() go where they want, whilst allowing the
instantiator to request that the key is retained. This is mainly useful for
situations where the instantiator makes a secondary request, the key for which
should be retained by the initial requestor:
+-----------+ +--------------+ +--------------+
| | | | | |
| Requestor |------->| Instantiator |------->| Instantiator |
| | | | | |
+-----------+ +--------------+ +--------------+
request_key() request_key()
This might be useful, for example, in Kerberos, where the requestor requests a
ticket, and then the ticket instantiator requests the TGT, which someone else
then has to go and fetch. The TGT, however, should be retained in the
keyrings of the requestor, not the first instantiator. To make this explict
an extra special keyring constant is also added.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <jmorris@namei.org>
Signed-off-by: James Morris <jmorris@namei.org>
2008-11-13 16:39:14 -07:00
|
|
|
#define KEY_REQKEY_DEFL_REQUESTOR_KEYRING 7
|
[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
(1) There's a new special key type called ".request_key_auth".
This is an authorisation key for when one process requests a key and
another process is started to construct it. This type of key cannot be
created by the user; nor can it be requested by kernel services.
Authorisation keys hold two references:
(a) Each refers to a key being constructed. When the key being
constructed is instantiated the authorisation key is revoked,
rendering it of no further use.
(b) The "authorising process". This is either:
(i) the process that called request_key(), or:
(ii) if the process that called request_key() itself had an
authorisation key in its session keyring, then the authorising
process referred to by that authorisation key will also be
referred to by the new authorisation key.
This means that the process that initiated a chain of key requests
will authorise the lot of them, and will, by default, wind up with
the keys obtained from them in its keyrings.
(2) request_key() creates an authorisation key which is then passed to
/sbin/request-key in as part of a new session keyring.
(3) When request_key() is searching for a key to hand back to the caller, if
it comes across an authorisation key in the session keyring of the
calling process, it will also search the keyrings of the process
specified therein and it will use the specified process's credentials
(fsuid, fsgid, groups) to do that rather than the calling process's
credentials.
This allows a process started by /sbin/request-key to find keys belonging
to the authorising process.
(4) A key can be read, even if the process executing KEYCTL_READ doesn't have
direct read or search permission if that key is contained within the
keyrings of a process specified by an authorisation key found within the
calling process's session keyring, and is searchable using the
credentials of the authorising process.
This allows a process started by /sbin/request-key to read keys belonging
to the authorising process.
(5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
KEYCTL_NEGATE will specify a keyring of the authorising process, rather
than the process doing the instantiation.
(6) One of the process keyrings can be nominated as the default to which
request_key() should attach new keys if not otherwise specified. This is
done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
constants. The current setting can also be read using this call.
(7) request_key() is partially interruptible. If it is waiting for another
process to finish constructing a key, it can be interrupted. This permits
a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 23:00:56 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* keyctl commands */
|
|
|
|
#define KEYCTL_GET_KEYRING_ID 0 /* ask for a keyring's ID */
|
|
|
|
#define KEYCTL_JOIN_SESSION_KEYRING 1 /* join or start named session keyring */
|
|
|
|
#define KEYCTL_UPDATE 2 /* update a key */
|
|
|
|
#define KEYCTL_REVOKE 3 /* revoke a key */
|
|
|
|
#define KEYCTL_CHOWN 4 /* set ownership of a key */
|
|
|
|
#define KEYCTL_SETPERM 5 /* set perms on a key */
|
|
|
|
#define KEYCTL_DESCRIBE 6 /* describe a key */
|
|
|
|
#define KEYCTL_CLEAR 7 /* clear contents of a keyring */
|
|
|
|
#define KEYCTL_LINK 8 /* link a key into a keyring */
|
|
|
|
#define KEYCTL_UNLINK 9 /* unlink a key from a keyring */
|
|
|
|
#define KEYCTL_SEARCH 10 /* search for a key in a keyring */
|
|
|
|
#define KEYCTL_READ 11 /* read a key or keyring's contents */
|
|
|
|
#define KEYCTL_INSTANTIATE 12 /* instantiate a partially constructed key */
|
|
|
|
#define KEYCTL_NEGATE 13 /* negate a partially constructed key */
|
[PATCH] Keys: Make request-key create an authorisation key
The attached patch makes the following changes:
(1) There's a new special key type called ".request_key_auth".
This is an authorisation key for when one process requests a key and
another process is started to construct it. This type of key cannot be
created by the user; nor can it be requested by kernel services.
Authorisation keys hold two references:
(a) Each refers to a key being constructed. When the key being
constructed is instantiated the authorisation key is revoked,
rendering it of no further use.
(b) The "authorising process". This is either:
(i) the process that called request_key(), or:
(ii) if the process that called request_key() itself had an
authorisation key in its session keyring, then the authorising
process referred to by that authorisation key will also be
referred to by the new authorisation key.
This means that the process that initiated a chain of key requests
will authorise the lot of them, and will, by default, wind up with
the keys obtained from them in its keyrings.
(2) request_key() creates an authorisation key which is then passed to
/sbin/request-key in as part of a new session keyring.
(3) When request_key() is searching for a key to hand back to the caller, if
it comes across an authorisation key in the session keyring of the
calling process, it will also search the keyrings of the process
specified therein and it will use the specified process's credentials
(fsuid, fsgid, groups) to do that rather than the calling process's
credentials.
This allows a process started by /sbin/request-key to find keys belonging
to the authorising process.
(4) A key can be read, even if the process executing KEYCTL_READ doesn't have
direct read or search permission if that key is contained within the
keyrings of a process specified by an authorisation key found within the
calling process's session keyring, and is searchable using the
credentials of the authorising process.
This allows a process started by /sbin/request-key to read keys belonging
to the authorising process.
(5) The magic KEY_SPEC_*_KEYRING key IDs when passed to KEYCTL_INSTANTIATE or
KEYCTL_NEGATE will specify a keyring of the authorising process, rather
than the process doing the instantiation.
(6) One of the process keyrings can be nominated as the default to which
request_key() should attach new keys if not otherwise specified. This is
done with KEYCTL_SET_REQKEY_KEYRING and one of the KEY_REQKEY_DEFL_*
constants. The current setting can also be read using this call.
(7) request_key() is partially interruptible. If it is waiting for another
process to finish constructing a key, it can be interrupted. This permits
a request-key cycle to be broken without recourse to rebooting.
Signed-Off-By: David Howells <dhowells@redhat.com>
Signed-Off-By: Benoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-23 23:00:56 -06:00
|
|
|
#define KEYCTL_SET_REQKEY_KEYRING 14 /* set default request-key keyring */
|
2006-01-08 02:02:43 -07:00
|
|
|
#define KEYCTL_SET_TIMEOUT 15 /* set key timeout */
|
2006-01-08 02:02:47 -07:00
|
|
|
#define KEYCTL_ASSUME_AUTHORITY 16 /* assume request_key() authorisation */
|
2008-04-29 02:01:26 -06:00
|
|
|
#define KEYCTL_GET_SECURITY 17 /* get key security label */
|
KEYS: Add a keyctl to install a process's session keyring on its parent [try #6]
Add a keyctl to install a process's session keyring onto its parent. This
replaces the parent's session keyring. Because the COW credential code does
not permit one process to change another process's credentials directly, the
change is deferred until userspace next starts executing again. Normally this
will be after a wait*() syscall.
To support this, three new security hooks have been provided:
cred_alloc_blank() to allocate unset security creds, cred_transfer() to fill in
the blank security creds and key_session_to_parent() - which asks the LSM if
the process may replace its parent's session keyring.
The replacement may only happen if the process has the same ownership details
as its parent, and the process has LINK permission on the session keyring, and
the session keyring is owned by the process, and the LSM permits it.
Note that this requires alteration to each architecture's notify_resume path.
This has been done for all arches barring blackfin, m68k* and xtensa, all of
which need assembly alteration to support TIF_NOTIFY_RESUME. This allows the
replacement to be performed at the point the parent process resumes userspace
execution.
This allows the userspace AFS pioctl emulation to fully emulate newpag() and
the VIOCSETTOK and VIOCSETTOK2 pioctls, all of which require the ability to
alter the parent process's PAG membership. However, since kAFS doesn't use
PAGs per se, but rather dumps the keys into the session keyring, the session
keyring of the parent must be replaced if, for example, VIOCSETTOK is passed
the newpag flag.
This can be tested with the following program:
#include <stdio.h>
#include <stdlib.h>
#include <keyutils.h>
#define KEYCTL_SESSION_TO_PARENT 18
#define OSERROR(X, S) do { if ((long)(X) == -1) { perror(S); exit(1); } } while(0)
int main(int argc, char **argv)
{
key_serial_t keyring, key;
long ret;
keyring = keyctl_join_session_keyring(argv[1]);
OSERROR(keyring, "keyctl_join_session_keyring");
key = add_key("user", "a", "b", 1, keyring);
OSERROR(key, "add_key");
ret = keyctl(KEYCTL_SESSION_TO_PARENT);
OSERROR(ret, "KEYCTL_SESSION_TO_PARENT");
return 0;
}
Compiled and linked with -lkeyutils, you should see something like:
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
355907932 --alswrv 4043 -1 \_ keyring: _uid.4043
[dhowells@andromeda ~]$ /tmp/newpag
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: _ses
1055658746 --alswrv 4043 4043 \_ user: a
[dhowells@andromeda ~]$ /tmp/newpag hello
[dhowells@andromeda ~]$ keyctl show
Session Keyring
-3 --alswrv 4043 4043 keyring: hello
340417692 --alswrv 4043 4043 \_ user: a
Where the test program creates a new session keyring, sticks a user key named
'a' into it and then installs it on its parent.
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02 02:14:21 -06:00
|
|
|
#define KEYCTL_SESSION_TO_PARENT 18 /* apply session keyring to parent process */
|
2011-03-07 08:06:09 -07:00
|
|
|
#define KEYCTL_REJECT 19 /* reject a partially constructed key */
|
2011-03-07 08:06:20 -07:00
|
|
|
#define KEYCTL_INSTANTIATE_IOV 20 /* instantiate a partially constructed key */
|
2012-05-11 03:56:56 -06:00
|
|
|
#define KEYCTL_INVALIDATE 21 /* invalidate a key */
|
2013-09-24 03:35:19 -06:00
|
|
|
#define KEYCTL_GET_PERSISTENT 22 /* get a user's persistent keyring */
|
2016-04-12 12:54:58 -06:00
|
|
|
#define KEYCTL_DH_COMPUTE 23 /* Compute Diffie-Hellman values */
|
KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]
Provide five keyctl functions that permit userspace to make use of the new
key type ops for accessing and driving asymmetric keys.
(*) Query an asymmetric key.
long keyctl(KEYCTL_PKEY_QUERY,
key_serial_t key, unsigned long reserved,
struct keyctl_pkey_query *info);
Get information about an asymmetric key. The information is returned
in the keyctl_pkey_query struct:
__u32 supported_ops;
A bit mask of flags indicating which ops are supported. This is
constructed from a bitwise-OR of:
KEYCTL_SUPPORTS_{ENCRYPT,DECRYPT,SIGN,VERIFY}
__u32 key_size;
The size in bits of the key.
__u16 max_data_size;
__u16 max_sig_size;
__u16 max_enc_size;
__u16 max_dec_size;
The maximum sizes in bytes of a blob of data to be signed, a signature
blob, a blob to be encrypted and a blob to be decrypted.
reserved must be set to 0. This is intended for future use to hand
over one or more passphrases needed unlock a key.
If successful, 0 is returned. If the key is not an asymmetric key,
EOPNOTSUPP is returned.
(*) Encrypt, decrypt, sign or verify a blob using an asymmetric key.
long keyctl(KEYCTL_PKEY_ENCRYPT,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_DECRYPT,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_SIGN,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_VERIFY,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
const void *in2);
Use an asymmetric key to perform a public-key cryptographic operation
a blob of data.
The parameter block pointed to by params contains a number of integer
values:
__s32 key_id;
__u32 in_len;
__u32 out_len;
__u32 in2_len;
For a given operation, the in and out buffers are used as follows:
Operation ID in,in_len out,out_len in2,in2_len
======================= =============== =============== ===========
KEYCTL_PKEY_ENCRYPT Raw data Encrypted data -
KEYCTL_PKEY_DECRYPT Encrypted data Raw data -
KEYCTL_PKEY_SIGN Raw data Signature -
KEYCTL_PKEY_VERIFY Raw data - Signature
info is a string of key=value pairs that supply supplementary
information.
The __spare space in the parameter block must be set to 0. This is
intended, amongst other things, to allow the passing of passphrases
required to unlock a key.
If successful, encrypt, decrypt and sign all return the amount of data
written into the output buffer. Verification returns 0 on success.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Denis Kenzior <denkenz@gmail.com>
Tested-by: Denis Kenzior <denkenz@gmail.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
2018-10-09 10:46:59 -06:00
|
|
|
#define KEYCTL_PKEY_QUERY 24 /* Query public key parameters */
|
|
|
|
#define KEYCTL_PKEY_ENCRYPT 25 /* Encrypt a blob using a public key */
|
|
|
|
#define KEYCTL_PKEY_DECRYPT 26 /* Decrypt a blob using a public key */
|
|
|
|
#define KEYCTL_PKEY_SIGN 27 /* Create a public key signature */
|
|
|
|
#define KEYCTL_PKEY_VERIFY 28 /* Verify a public key signature */
|
2017-03-01 17:44:09 -07:00
|
|
|
#define KEYCTL_RESTRICT_KEYRING 29 /* Restrict keys allowed to link to a keyring */
|
2019-05-20 14:51:50 -06:00
|
|
|
#define KEYCTL_MOVE 30 /* Move keys between keyrings */
|
2019-05-30 07:53:10 -06:00
|
|
|
#define KEYCTL_CAPABILITIES 31 /* Find capabilities of keyrings subsystem */
|
keys: Provide KEYCTL_GRANT_PERMISSION
Provide a keyctl() operation to grant/remove permissions. The grant
operation, wrapped by libkeyutils, looks like:
int ret = keyctl_grant_permission(key_serial_t key,
enum key_ace_subject_type type,
unsigned int subject,
unsigned int perm);
Where key is the key to be modified, type and subject represent the subject
to which permission is to be granted (or removed) and perm is the set of
permissions to be granted. 0 is returned on success. SET_SECURITY
permission is required for this.
The subject type currently must be KEY_ACE_SUBJ_STANDARD for the moment
(other subject types will come along later).
For subject type KEY_ACE_SUBJ_STANDARD, the following subject values are
available:
KEY_ACE_POSSESSOR The possessor of the key
KEY_ACE_OWNER The owner of the key
KEY_ACE_GROUP The key's group
KEY_ACE_EVERYONE Everyone
perm lists the permissions to be granted:
KEY_ACE_VIEW Can view the key metadata
KEY_ACE_READ Can read the key content
KEY_ACE_WRITE Can update/modify the key content
KEY_ACE_SEARCH Can find the key by searching/requesting
KEY_ACE_LINK Can make a link to the key
KEY_ACE_SET_SECURITY Can set security
KEY_ACE_INVAL Can invalidate
KEY_ACE_REVOKE Can revoke
KEY_ACE_JOIN Can join this keyring
KEY_ACE_CLEAR Can clear this keyring
If an ACE already exists for the subject, then the permissions mask will be
overwritten; if perm is 0, it will be deleted.
Currently, the internal ACL is limited to a maximum of 16 entries.
For example:
int ret = keyctl_grant_permission(key,
KEY_ACE_SUBJ_STANDARD,
KEY_ACE_OWNER,
KEY_ACE_VIEW | KEY_ACE_READ);
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-27 16:03:07 -06:00
|
|
|
#define KEYCTL_GRANT_PERMISSION 32 /* Grant a permit to a key */
|
2016-04-12 12:54:58 -06:00
|
|
|
|
|
|
|
/* keyctl structures */
|
|
|
|
struct keyctl_dh_params {
|
2018-09-27 17:51:20 -06:00
|
|
|
union {
|
|
|
|
#ifndef __cplusplus
|
|
|
|
__s32 private;
|
|
|
|
#endif
|
|
|
|
__s32 priv;
|
|
|
|
};
|
2016-04-12 12:54:58 -06:00
|
|
|
__s32 prime;
|
|
|
|
__s32 base;
|
|
|
|
};
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2016-08-19 12:39:09 -06:00
|
|
|
struct keyctl_kdf_params {
|
2017-06-08 07:49:57 -06:00
|
|
|
char __user *hashname;
|
|
|
|
char __user *otherinfo;
|
2016-08-19 12:39:09 -06:00
|
|
|
__u32 otherinfolen;
|
|
|
|
__u32 __spare[8];
|
|
|
|
};
|
|
|
|
|
2018-10-09 10:46:51 -06:00
|
|
|
#define KEYCTL_SUPPORTS_ENCRYPT 0x01
|
|
|
|
#define KEYCTL_SUPPORTS_DECRYPT 0x02
|
|
|
|
#define KEYCTL_SUPPORTS_SIGN 0x04
|
|
|
|
#define KEYCTL_SUPPORTS_VERIFY 0x08
|
|
|
|
|
KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver #2]
Provide five keyctl functions that permit userspace to make use of the new
key type ops for accessing and driving asymmetric keys.
(*) Query an asymmetric key.
long keyctl(KEYCTL_PKEY_QUERY,
key_serial_t key, unsigned long reserved,
struct keyctl_pkey_query *info);
Get information about an asymmetric key. The information is returned
in the keyctl_pkey_query struct:
__u32 supported_ops;
A bit mask of flags indicating which ops are supported. This is
constructed from a bitwise-OR of:
KEYCTL_SUPPORTS_{ENCRYPT,DECRYPT,SIGN,VERIFY}
__u32 key_size;
The size in bits of the key.
__u16 max_data_size;
__u16 max_sig_size;
__u16 max_enc_size;
__u16 max_dec_size;
The maximum sizes in bytes of a blob of data to be signed, a signature
blob, a blob to be encrypted and a blob to be decrypted.
reserved must be set to 0. This is intended for future use to hand
over one or more passphrases needed unlock a key.
If successful, 0 is returned. If the key is not an asymmetric key,
EOPNOTSUPP is returned.
(*) Encrypt, decrypt, sign or verify a blob using an asymmetric key.
long keyctl(KEYCTL_PKEY_ENCRYPT,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_DECRYPT,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_SIGN,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
void *out);
long keyctl(KEYCTL_PKEY_VERIFY,
const struct keyctl_pkey_params *params,
const char *info,
const void *in,
const void *in2);
Use an asymmetric key to perform a public-key cryptographic operation
a blob of data.
The parameter block pointed to by params contains a number of integer
values:
__s32 key_id;
__u32 in_len;
__u32 out_len;
__u32 in2_len;
For a given operation, the in and out buffers are used as follows:
Operation ID in,in_len out,out_len in2,in2_len
======================= =============== =============== ===========
KEYCTL_PKEY_ENCRYPT Raw data Encrypted data -
KEYCTL_PKEY_DECRYPT Encrypted data Raw data -
KEYCTL_PKEY_SIGN Raw data Signature -
KEYCTL_PKEY_VERIFY Raw data - Signature
info is a string of key=value pairs that supply supplementary
information.
The __spare space in the parameter block must be set to 0. This is
intended, amongst other things, to allow the passing of passphrases
required to unlock a key.
If successful, encrypt, decrypt and sign all return the amount of data
written into the output buffer. Verification returns 0 on success.
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Marcel Holtmann <marcel@holtmann.org>
Reviewed-by: Denis Kenzior <denkenz@gmail.com>
Tested-by: Denis Kenzior <denkenz@gmail.com>
Signed-off-by: James Morris <james.morris@microsoft.com>
2018-10-09 10:46:59 -06:00
|
|
|
struct keyctl_pkey_query {
|
|
|
|
__u32 supported_ops; /* Which ops are supported */
|
|
|
|
__u32 key_size; /* Size of the key in bits */
|
|
|
|
__u16 max_data_size; /* Maximum size of raw data to sign in bytes */
|
|
|
|
__u16 max_sig_size; /* Maximum size of signature in bytes */
|
|
|
|
__u16 max_enc_size; /* Maximum size of encrypted blob in bytes */
|
|
|
|
__u16 max_dec_size; /* Maximum size of decrypted blob in bytes */
|
|
|
|
__u32 __spare[10];
|
|
|
|
};
|
|
|
|
|
|
|
|
struct keyctl_pkey_params {
|
|
|
|
__s32 key_id; /* Serial no. of public key to use */
|
|
|
|
__u32 in_len; /* Input data size */
|
|
|
|
union {
|
|
|
|
__u32 out_len; /* Output buffer size (encrypt/decrypt/sign) */
|
|
|
|
__u32 in2_len; /* 2nd input data size (verify) */
|
|
|
|
};
|
|
|
|
__u32 __spare[7];
|
|
|
|
};
|
|
|
|
|
2019-05-20 14:51:50 -06:00
|
|
|
#define KEYCTL_MOVE_EXCL 0x00000001 /* Do not displace from the to-keyring */
|
|
|
|
|
2019-05-30 07:53:10 -06:00
|
|
|
/*
|
|
|
|
* Capabilities flags. The capabilities list is an array of 8-bit integers;
|
|
|
|
* each integer can carry up to 8 flags.
|
|
|
|
*/
|
|
|
|
#define KEYCTL_CAPS0_CAPABILITIES 0x01 /* KEYCTL_CAPABILITIES supported */
|
|
|
|
#define KEYCTL_CAPS0_PERSISTENT_KEYRINGS 0x02 /* Persistent keyrings enabled */
|
|
|
|
#define KEYCTL_CAPS0_DIFFIE_HELLMAN 0x04 /* Diffie-Hellman computation enabled */
|
|
|
|
#define KEYCTL_CAPS0_PUBLIC_KEY 0x08 /* Public key ops enabled */
|
|
|
|
#define KEYCTL_CAPS0_BIG_KEY 0x10 /* big_key-type enabled */
|
|
|
|
#define KEYCTL_CAPS0_INVALIDATE 0x20 /* KEYCTL_INVALIDATE supported */
|
|
|
|
#define KEYCTL_CAPS0_RESTRICT_KEYRING 0x40 /* KEYCTL_RESTRICT_KEYRING supported */
|
|
|
|
#define KEYCTL_CAPS0_MOVE 0x80 /* KEYCTL_MOVE supported */
|
2019-06-26 14:02:32 -06:00
|
|
|
#define KEYCTL_CAPS1_NS_KEYRING_NAME 0x01 /* Keyring names are per-user_namespace */
|
2019-06-26 14:02:32 -06:00
|
|
|
#define KEYCTL_CAPS1_NS_KEY_TAG 0x02 /* Key indexing can include a namespace tag */
|
keys: Provide KEYCTL_GRANT_PERMISSION
Provide a keyctl() operation to grant/remove permissions. The grant
operation, wrapped by libkeyutils, looks like:
int ret = keyctl_grant_permission(key_serial_t key,
enum key_ace_subject_type type,
unsigned int subject,
unsigned int perm);
Where key is the key to be modified, type and subject represent the subject
to which permission is to be granted (or removed) and perm is the set of
permissions to be granted. 0 is returned on success. SET_SECURITY
permission is required for this.
The subject type currently must be KEY_ACE_SUBJ_STANDARD for the moment
(other subject types will come along later).
For subject type KEY_ACE_SUBJ_STANDARD, the following subject values are
available:
KEY_ACE_POSSESSOR The possessor of the key
KEY_ACE_OWNER The owner of the key
KEY_ACE_GROUP The key's group
KEY_ACE_EVERYONE Everyone
perm lists the permissions to be granted:
KEY_ACE_VIEW Can view the key metadata
KEY_ACE_READ Can read the key content
KEY_ACE_WRITE Can update/modify the key content
KEY_ACE_SEARCH Can find the key by searching/requesting
KEY_ACE_LINK Can make a link to the key
KEY_ACE_SET_SECURITY Can set security
KEY_ACE_INVAL Can invalidate
KEY_ACE_REVOKE Can revoke
KEY_ACE_JOIN Can join this keyring
KEY_ACE_CLEAR Can clear this keyring
If an ACE already exists for the subject, then the permissions mask will be
overwritten; if perm is 0, it will be deleted.
Currently, the internal ACL is limited to a maximum of 16 entries.
For example:
int ret = keyctl_grant_permission(key,
KEY_ACE_SUBJ_STANDARD,
KEY_ACE_OWNER,
KEY_ACE_VIEW | KEY_ACE_READ);
Signed-off-by: David Howells <dhowells@redhat.com>
2019-06-27 16:03:07 -06:00
|
|
|
#define KEYCTL_CAPS1_ACL_ALTERABLE 0x04 /* Keys have internal ACL that can be altered */
|
2019-05-30 07:53:10 -06:00
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
#endif /* _LINUX_KEYCTL_H */
|