From 4eb582cf1fbd7b9e5f466e3718a59c957e75254e Mon Sep 17 00:00:00 2001 From: Michael LeMay Date: Mon, 26 Jun 2006 00:24:57 -0700 Subject: [PATCH] keys: add a way to store the appropriate context for newly-created keys Add a /proc//attr/keycreate entry that stores the appropriate context for newly-created keys. Modify the selinux_key_alloc hook to make use of the new entry. Update the flask headers to include a new "setkeycreate" permission for processes. Update the flask headers to include a new "create" permission for keys. Use the create permission to restrict which SIDs each task can assign to newly-created keys. Add a new parameter to the security hook "security_key_alloc" to indicate whether it is being invoked by the kernel, or from userspace. If it is being invoked by the kernel, the security hook should never fail. Update the documentation to reflect these changes. Signed-off-by: Michael LeMay Signed-off-by: James Morris Signed-off-by: David Howells Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/keys.txt | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) (limited to 'Documentation/keys.txt') diff --git a/Documentation/keys.txt b/Documentation/keys.txt index 70e83cf664ae..61c0fad2fe2f 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt @@ -241,25 +241,30 @@ The security class "key" has been added to SELinux so that mandatory access controls can be applied to keys created within various contexts. This support is preliminary, and is likely to change quite significantly in the near future. Currently, all of the basic permissions explained above are provided in SELinux -as well; SE Linux is simply invoked after all basic permission checks have been +as well; SELinux is simply invoked after all basic permission checks have been performed. -Each key is labeled with the same context as the task to which it belongs. -Typically, this is the same task that was running when the key was created. -The default keyrings are handled differently, but in a way that is very -intuitive: +The value of the file /proc/self/attr/keycreate influences the labeling of +newly-created keys. If the contents of that file correspond to an SELinux +security context, then the key will be assigned that context. Otherwise, the +key will be assigned the current context of the task that invoked the key +creation request. Tasks must be granted explicit permission to assign a +particular context to newly-created keys, using the "create" permission in the +key security class. - (*) The user and user session keyrings that are created when the user logs in - are currently labeled with the context of the login manager. - - (*) The keyrings associated with new threads are each labeled with the context - of their associated thread, and both session and process keyrings are - handled similarly. +The default keyrings associated with users will be labeled with the default +context of the user if and only if the login programs have been instrumented to +properly initialize keycreate during the login process. Otherwise, they will +be labeled with the context of the login program itself. Note, however, that the default keyrings associated with the root user are labeled with the default kernel context, since they are created early in the boot process, before root has a chance to log in. +The keyrings associated with new threads are each labeled with the context of +their associated thread, and both session and process keyrings are handled +similarly. + ================ NEW PROCFS FILES -- cgit v1.2.3-59-g8ed1b