summaryrefslogtreecommitdiffstats
path: root/security/keys/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2013-09-24KEYS: Add per-user_namespace registers for persistent per-UID kerberos cachesDavid Howells1-0/+1
Add support for per-user_namespace registers of persistent per-UID kerberos caches held within the kernel. This allows the kerberos cache to be retained beyond the life of all a user's processes so that the user's cron jobs can work. The kerberos cache is envisioned as a keyring/key tree looking something like: struct user_namespace \___ .krb_cache keyring - The register \___ _krb.0 keyring - Root's Kerberos cache \___ _krb.5000 keyring - User 5000's Kerberos cache \___ _krb.5001 keyring - User 5001's Kerberos cache \___ tkt785 big_key - A ccache blob \___ tkt12345 big_key - Another ccache blob Or possibly: struct user_namespace \___ .krb_cache keyring - The register \___ _krb.0 keyring - Root's Kerberos cache \___ _krb.5000 keyring - User 5000's Kerberos cache \___ _krb.5001 keyring - User 5001's Kerberos cache \___ tkt785 keyring - A ccache \___ krbtgt/REDHAT.COM@REDHAT.COM big_key \___ http/REDHAT.COM@REDHAT.COM user \___ afs/REDHAT.COM@REDHAT.COM user \___ nfs/REDHAT.COM@REDHAT.COM user \___ krbtgt/KERNEL.ORG@KERNEL.ORG big_key \___ http/KERNEL.ORG@KERNEL.ORG big_key What goes into a particular Kerberos cache is entirely up to userspace. Kernel support is limited to giving you the Kerberos cache keyring that you want. The user asks for their Kerberos cache by: krb_cache = keyctl_get_krbcache(uid, dest_keyring); The uid is -1 or the user's own UID for the user's own cache or the uid of some other user's cache (requires CAP_SETUID). This permits rpc.gssd or whatever to mess with the cache. The cache returned is a keyring named "_krb.<uid>" that the possessor can read, search, clear, invalidate, unlink from and add links to. Active LSMs get a chance to rule on whether the caller is permitted to make a link. Each uid's cache keyring is created when it first accessed and is given a timeout that is extended each time this function is called so that the keyring goes away after a while. The timeout is configurable by sysctl but defaults to three days. Each user_namespace struct gets a lazily-created keyring that serves as the register. The cache keyrings are added to it. This means that standard key search and garbage collection facilities are available. The user_namespace struct's register goes away when it does and anything left in it is then automatically gc'd. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Simo Sorce <simo@redhat.com> cc: Serge E. Hallyn <serge.hallyn@ubuntu.com> cc: Eric W. Biederman <ebiederm@xmission.com>
2013-09-24KEYS: Implement a big key type that can save to tmpfsDavid Howells1-0/+1
Implement a big key type that can save its contents to tmpfs and thus swapspace when memory is tight. This is useful for Kerberos ticket caches. Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Simo Sorce <simo@redhat.com>
2012-05-11KEYS: Reorganise keys MakefileDavid Howells1-3/+9
Reorganise the keys directory Makefile to put all the core bits together and the type-specific bits after. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Mimi Zohar <zohar@us.ibm.com>
2011-09-14encrypted-keys: create encrypted-keys directoryMimi Zohar1-1/+1
Move all files associated with encrypted keys to keys/encrypted-keys. Signed-off-by: Mimi Zohar <zohar@us.ibm.com>
2011-06-27encrypted-keys: add ecryptfs format supportRoberto Sassu1-1/+1
The 'encrypted' key type defines its own payload format which contains a symmetric key randomly generated that cannot be used directly to mount an eCryptfs filesystem, because it expects an authentication token structure. This patch introduces the new format 'ecryptfs' that allows to store an authentication token structure inside the encrypted key payload containing a randomly generated symmetric key, as the same for the format 'default'. More details about the usage of encrypted keys with the eCryptfs filesystem can be found in the file 'Documentation/keys-ecryptfs.txt'. Signed-off-by: Roberto Sassu <roberto.sassu@polito.it> Acked-by: Gianluca Ramunno <ramunno@polito.it> Acked-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2011-01-24encrypted-keys: rename encrypted_defined files to encryptedMimi Zohar1-1/+1
Rename encrypted_defined.c and encrypted_defined.h files to encrypted.c and encrypted.h, respectively. Based on request from David Howells. Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2011-01-24trusted-keys: rename trusted_defined files to trustedMimi Zohar1-1/+1
Rename trusted_defined.c and trusted_defined.h files to trusted.c and trusted.h, respectively. Based on request from David Howells. Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2010-11-29keys: add new key-type encryptedMimi Zohar1-0/+1
Define a new kernel key-type called 'encrypted'. Encrypted keys are kernel generated random numbers, which are encrypted/decrypted with a 'trusted' symmetric key. Encrypted keys are created/encrypted/decrypted in the kernel. Userspace only ever sees/stores encrypted blobs. Changelog: - bug fix: replaced master-key rcu based locking with semaphore (reported by David Howells) - Removed memset of crypto_shash_digest() digest output - Replaced verification of 'key-type:key-desc' using strcspn(), with one based on string constants. - Moved documentation to Documentation/keys-trusted-encrypted.txt - Replace hash with shash (based on comments by David Howells) - Make lengths/counts size_t where possible (based on comments by David Howells) Could not convert most lengths, as crypto expects 'unsigned int' (size_t: on 32 bit is defined as unsigned int, but on 64 bit is unsigned long) - Add 'const' where possible (based on comments by David Howells) - allocate derived_buf dynamically to support arbitrary length master key (fixed by Roberto Sassu) - wait until late_initcall for crypto libraries to be registered - cleanup security/Kconfig - Add missing 'update' keyword (reported/fixed by Roberto Sassu) - Free epayload on failure to create key (reported/fixed by Roberto Sassu) - Increase the data size limit (requested by Roberto Sassu) - Crypto return codes are always 0 on success and negative on failure, remove unnecessary tests. - Replaced kzalloc() with kmalloc() Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Signed-off-by: David Safford <safford@watson.ibm.com> Reviewed-by: Roberto Sassu <roberto.sassu@polito.it> Signed-off-by: James Morris <jmorris@namei.org>
2010-11-29keys: add new trusted key-typeMimi Zohar1-0/+1
Define a new kernel key-type called 'trusted'. Trusted keys are random number symmetric keys, generated and RSA-sealed by the TPM. The TPM only unseals the keys, if the boot PCRs and other criteria match. Userspace can only ever see encrypted blobs. Based on suggestions by Jason Gunthorpe, several new options have been added to support additional usages. The new options are: migratable= designates that the key may/may not ever be updated (resealed under a new key, new pcrinfo or new auth.) pcrlock=n extends the designated PCR 'n' with a random value, so that a key sealed to that PCR may not be unsealed again until after a reboot. keyhandle= specifies the sealing/unsealing key handle. keyauth= specifies the sealing/unsealing key auth. blobauth= specifies the sealed data auth. Implementation of a kernel reserved locality for trusted keys will be investigated for a possible future extension. Changelog: - Updated and added examples to Documentation/keys-trusted-encrypted.txt - Moved generic TPM constants to include/linux/tpm_command.h (David Howell's suggestion.) - trusted_defined.c: replaced kzalloc with kmalloc, added pcrlock failure error handling, added const qualifiers where appropriate. - moved to late_initcall - updated from hash to shash (suggestion by David Howells) - reduced worst stack usage (tpm_seal) from 530 to 312 bytes - moved documentation to Documentation directory (suggestion by David Howells) - all the other code cleanups suggested by David Howells - Add pcrlock CAP_SYS_ADMIN dependency (based on comment by Jason Gunthorpe) - New options: migratable, pcrlock, keyhandle, keyauth, blobauth (based on discussions with Jason Gunthorpe) - Free payload on failure to create key(reported/fixed by Roberto Sassu) - Updated Kconfig and other descriptions (based on Serge Hallyn's suggestion) - Replaced kzalloc() with kmalloc() (reported by Serge Hallyn) Signed-off-by: David Safford <safford@watson.ibm.com> Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-09-02KEYS: Add garbage collection for dead, revoked and expired keys. [try #6]David Howells1-0/+1
Add garbage collection for dead, revoked and expired keys. This involved erasing all links to such keys from keyrings that point to them. At that point, the key will be deleted in the normal manner. Keyrings from which garbage collection occurs are shrunk and their quota consumption reduced as appropriate. Dead keys (for which the key type has been removed) will be garbage collected immediately. Revoked and expired keys will hang around for a number of seconds, as set in /proc/sys/kernel/keys/gc_delay before being automatically removed. The default is 5 minutes. Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2008-04-29keys: make the keyring quotas controllable through /proc/sysDavid Howells1-0/+1
Make the keyring quotas controllable through /proc/sys files: (*) /proc/sys/kernel/keys/root_maxkeys /proc/sys/kernel/keys/root_maxbytes Maximum number of keys that root may have and the maximum total number of bytes of data that root may have stored in those keys. (*) /proc/sys/kernel/keys/maxkeys /proc/sys/kernel/keys/maxbytes Maximum number of keys that each non-root user may have and the maximum total number of bytes of data that each of those users may have stored in their keys. Also increase the quotas as a number of people have been complaining that it's not big enough. I'm not sure that it's big enough now either, but on the other hand, it can now be set in /etc/sysctl.conf. Signed-off-by: David Howells <dhowells@redhat.com> Cc: <kwc@citi.umich.edu> Cc: <arunsr@cse.iitk.ac.in> Cc: <dwalsh@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2005-10-08[PATCH] Keys: Split key permissions checking into a .c fileDavid Howells1-0/+1
The attached patch splits key permissions checking out of key-ui.h and moves it into a .c file. It's quite large and called quite a lot, and it's about to get bigger with the addition of LSM support for keys... key_any_permission() is also discarded as it's no longer used. Signed-Off-By: David Howells <dhowells@redhat.com> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-24[PATCH] Keys: Make request-key create an authorisation keyDavid Howells1-2/+3
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-04-16Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds1-0/+14
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!