linux/Documentation/security, branch v3.13.2

ima: new templates management mechanism

2013-10-25T21:17:04Z

The original 'ima' template is fixed length, containing the filedata hash and pathname. The filedata hash is limited to 20 bytes (md5/sha1). The pathname is a null terminated string, limited to 255 characters. To overcome these limitations and to add additional file metadata, it is necessary to extend the current version of IMA by defining additional templates. The main reason to introduce this feature is that, each time a new template is defined, the functions that generate and display the measurement list would include the code for handling a new format and, thus, would significantly grow over time. This patch set solves this problem by separating the template management from the remaining IMA code. The core of this solution is the definition of two new data structures: a template descriptor, to determine which information should be included in the measurement list, and a template field, to generate and display data of a given type. To define a new template field, developers define the field identifier and implement two functions, init() and show(), respectively to generate and display measurement entries. Initially, this patch set defines the following template fields (support for additional data types will be added later): - 'd': the digest of the event (i.e. the digest of a measured file), calculated with the SHA1 or MD5 hash algorithm; - 'n': the name of the event (i.e. the file name), with size up to 255 bytes; - 'd-ng': the digest of the event, calculated with an arbitrary hash algorithm (field format: [:]digest, where the digest prefix is shown only if the hash algorithm is not SHA1 or MD5); - 'n-ng': the name of the event, without size limitations. Defining a new template descriptor requires specifying the template format, a string of field identifiers separated by the '|' character. This patch set defines the following template descriptors: - "ima": its format is 'd|n'; - "ima-ng" (default): its format is 'd-ng|n-ng' Further details about the new template architecture can be found in Documentation/security/IMA-templates.txt. Changelog: - don't defer calling ima_init_template() - Mimi - don't define ima_lookup_template_desc() until used - Mimi - squashed with documentation patch - Mimi Signed-off-by: Roberto Sassu Signed-off-by: Mimi Zohar

KEYS: Define a __key_get() wrapper to use rather than atomic_inc()

2013-09-24T09:35:16Z

Define a __key_get() wrapper to use rather than atomic_inc() on the key usage count as this makes it easier to hook in refcount error debugging. Signed-off-by: David Howells

KEYS: Use bool in make_key_ref() and is_key_possessed()

2013-09-24T09:35:14Z

Make make_key_ref() take a bool possession parameter and make is_key_possessed() return a bool. Signed-off-by: David Howells

Smack: add support for modification of existing rules

2013-03-19T21:16:42Z

Rule modifications are enabled via /smack/change-rule. Format is as follows: "Subject Object rwaxt rwaxt" First two strings are subject and object labels up to 255 characters. Third string contains permissions to enable. Fourth string contains permissions to disable. All unmentioned permissions will be left unchanged. If no rule previously existed, it will be created. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Rafal Krypa

Documentation: fix Documentation/security/00-INDEX

2012-12-18T01:15:22Z

keys-ecryptfs.txt was missing from 00-INDEX. Signed-off-by: Jarkko Sakkinen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

Merge branch 'modsign-keys-devel' into security-next-keys

2012-10-02T18:30:19Z

Signed-off-by: David Howells

KEYS: Use keyring_alloc() to create special keyrings

2012-10-02T18:24:56Z

Use keyring_alloc() to create special keyrings now that it has a permissions parameter rather than using key_alloc() + key_instantiate_and_link(). Also document and export keyring_alloc() so that modules can use it too. Signed-off-by: David Howells

Documentation: Update git repository URL for Smack userland tools

2012-09-26T16:24:06Z

The userland git repository has been moved to a new place. Signed-off-by: Daniel Wagner Cc: Casey Schaufler Cc: Rob Landley Cc: linux-security-module@vger.kernel.org Cc: lkml@vger.kernel.org

Smack: implement revoking all rules for a subject label

2012-09-18T16:50:52Z

Add /smack/revoke-subject special file. Writing a SMACK label to this file will set the access to '-' for all access rules with that subject label. Targeted for git://git.gitorious.org/smack-next/kernel.git Signed-off-by: Rafal Krypa

KEYS: Add payload preparsing opportunity prior to key instantiate or update

2012-09-13T12:06:29Z

Give the key type the opportunity to preparse the payload prior to the instantiation and update routines being called. This is done with the provision of two new key type operations: int (*preparse)(struct key_preparsed_payload *prep); void (*free_preparse)(struct key_preparsed_payload *prep); If the first operation is present, then it is called before key creation (in the add/update case) or before the key semaphore is taken (in the update and instantiate cases). The second operation is called to clean up if the first was called. preparse() is given the opportunity to fill in the following structure: struct key_preparsed_payload { char *description; void *type_data[2]; void *payload; const void *data; size_t datalen; size_t quotalen; }; Before the preparser is called, the first three fields will have been cleared, the payload pointer and size will be stored in data and datalen and the default quota size from the key_type struct will be stored into quotalen. The preparser may parse the payload in any way it likes and may store data in the type_data[] and payload fields for use by the instantiate() and update() ops. The preparser may also propose a description for the key by attaching it as a string to the description field. This can be used by passing a NULL or "" description to the add_key() system call or the key_create_or_update() function. This cannot work with request_key() as that required the description to tell the upcall about the key to be created. This, for example permits keys that store PGP public keys to generate their own name from the user ID and public key fingerprint in the key. The instantiate() and update() operations are then modified to look like this: int (*instantiate)(struct key *key, struct key_preparsed_payload *prep); int (*update)(struct key *key, struct key_preparsed_payload *prep); and the new payload data is passed in *prep, whether or not it was preparsed. Signed-off-by: David Howells