summaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
authorMichael LeMay <mdlemay@epoch.ncsc.mil>2006-06-26 00:24:57 -0700
committerLinus Torvalds <torvalds@g5.osdl.org>2006-06-26 09:58:18 -0700
commit4eb582cf1fbd7b9e5f466e3718a59c957e75254e (patch)
tree4387e460a50efa8d46a54526d0cf0959c0e3b428 /Documentation
parent06ec7be557a1259611d6093a00463c42650dc71a (diff)
downloadtalos-op-linux-4eb582cf1fbd7b9e5f466e3718a59c957e75254e.tar.gz
talos-op-linux-4eb582cf1fbd7b9e5f466e3718a59c957e75254e.zip
[PATCH] keys: add a way to store the appropriate context for newly-created keys
Add a /proc/<pid>/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 <mdlemay@epoch.ncsc.mil> Signed-off-by: James Morris <jmorris@namei.org> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/keys.txt27
1 files changed, 16 insertions, 11 deletions
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
OpenPOWER on IntegriCloud