Commit 1873499e authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 

Pull security subsystem update from James Morris:
 "This is mostly maintenance updates across the subsystem, with a
  notable update for TPM 2.0, and addition of Jarkko Sakkinen as a
  maintainer of that"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (40 commits)
  apparmor: clarify CRYPTO dependency
  selinux: Use a kmem_cache for allocation struct file_security_struct
  selinux: ioctl_has_perm should be static
  selinux: use sprintf return value
  selinux: use kstrdup() in security_get_bools()
  selinux: use kmemdup in security_sid_to_context_core()
  selinux: remove pointless cast in selinux_inode_setsecurity()
  selinux: introduce security_context_str_to_sid
  selinux: do not check open perm on ftruncate call
  selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default
  KEYS: Merge the type-specific data with the payload data
  KEYS: Provide a script to extract a module signature
  KEYS: Provide a script to extract the sys cert list from a vmlinux file
  keys: Be more consistent in selection of union members used
  certs: add .gitignore to stop git nagging about x509_certificate_list
  KEYS: use kvfree() in add_key
  Smack: limited capability for changing process label
  TPM: remove unnecessary little endian conversion
  vTPM: support little endian guests
  char: Drop owner assignment from i2c_driver
  ...
parents 3460b01b ba94c3ff

Documentation/ABI/testing/sysfs-driver-ppi

+12 −7
Original line number Diff line number Diff line 
What:		/sys/devices/pnp0/<bus-num>/ppi/

What:		/sys/class/tpm/tpmX/ppi/

Date:		August 2012

Kernel Version:	3.6

Contact:	xiaoyan.zhang@intel.com
@@ -8,9 +8,14 @@ Description: 
		folder makes sense. The folder path can be got by command

		'find /sys/ -name 'pcrs''. For the detail information of PPI,

		please refer to the PPI specification from



		http://www.trustedcomputinggroup.org/



What:		/sys/devices/pnp0/<bus-num>/ppi/version

		In Linux 4.2 ppi was moved to the character device directory.

		A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards

		compatibility.



What:		/sys/class/tpm/tpmX/ppi/version

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:
@@ -18,7 +23,7 @@ Description: 
		platform.

		This file is readonly.



What:		/sys/devices/pnp0/<bus-num>/ppi/request

What:		/sys/class/tpm/tpmX/ppi/request

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:
@@ -28,7 +33,7 @@ Description: 
		integer value range from 1 to 160, and 0 means no request.

		This file can be read and written.



What:		/sys/devices/pnp0/00:<bus-num>/ppi/response

What:		/sys/class/tpm/tpmX/ppi/response

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:
@@ -37,7 +42,7 @@ Description: 
		: <response description>".

		This file is readonly.



What:		/sys/devices/pnp0/<bus-num>/ppi/transition_action

What:		/sys/class/tpm/tpmX/ppi/transition_action

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:
@@ -47,7 +52,7 @@ Description: 
		description>".

		This file is readonly.



What:		/sys/devices/pnp0/<bus-num>/ppi/tcg_operations

What:		/sys/class/tpm/tpmX/ppi/tcg_operations

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:
@@ -58,7 +63,7 @@ Description: 
		This attribute is only supported by PPI version 1.2+.

		This file is readonly.



What:		/sys/devices/pnp0/<bus-num>/ppi/vs_operations

What:		/sys/class/tpm/tpmX/ppi/vs_operations

Date:		August 2012

Contact:	xiaoyan.zhang@intel.com

Description:

Documentation/crypto/asymmetric-keys.txt

+14 −13
Original line number Diff line number Diff line
@@ -186,7 +186,7 @@ and looks like the following: 
					const struct public_key_signature *sig);

	};



Asymmetric keys point to this with their type_data[0] member.

Asymmetric keys point to this with their payload[asym_subtype] member.



The owner and name fields should be set to the owning module and the name of

the subtype.  Currently, the name is only used for print statements.
@@ -269,8 +269,7 @@ mandatory: 


	struct key_preparsed_payload {

		char		*description;

		void		*type_data[2];

		void		*payload;

		void		*payload[4];

		const void	*data;

		size_t		datalen;

		size_t		quotalen;
@@ -283,16 +282,18 @@ mandatory: 
     not theirs.



     If the parser is happy with the blob, it should propose a description for

     the key and attach it to ->description, ->type_data[0] should be set to

     point to the subtype to be used, ->payload should be set to point to the

     initialised data for that subtype, ->type_data[1] should point to a hex

     fingerprint and quotalen should be updated to indicate how much quota this

     key should account for.



     When clearing up, the data attached to ->type_data[1] and ->description

     will be kfree()'d and the data attached to ->payload will be passed to the

     subtype's ->destroy() method to be disposed of.  A module reference for

     the subtype pointed to by ->type_data[0] will be put.

     the key and attach it to ->description, ->payload[asym_subtype] should be

     set to point to the subtype to be used, ->payload[asym_crypto] should be

     set to point to the initialised data for that subtype,

     ->payload[asym_key_ids] should point to one or more hex fingerprints and

     quotalen should be updated to indicate how much quota this key should

     account for.



     When clearing up, the data attached to ->payload[asym_key_ids] and

     ->description will be kfree()'d and the data attached to

     ->payload[asm_crypto] will be passed to the subtype's ->destroy() method

     to be disposed of.  A module reference for the subtype pointed to by

     ->payload[asym_subtype] will be put.





     If the data format is not recognised, -EBADMSG should be returned.  If it

Documentation/security/Smack.txt

+10 −0
Original line number Diff line number Diff line
@@ -255,6 +255,16 @@ unconfined 
	the access permitted if it wouldn't be otherwise. Note that this

	is dangerous and can ruin the proper labeling of your system.

	It should never be used in production.

relabel-self

	This interface contains a list of labels to which the process can

	transition to, by writing to /proc/self/attr/current.

	Normally a process can change its own label to any legal value, but only

	if it has CAP_MAC_ADMIN. This interface allows a process without

	CAP_MAC_ADMIN to relabel itself to one of labels from predefined list.

	A process without CAP_MAC_ADMIN can change its label only once. When it

	does, this list will be cleared.

	The values are set by writing the desired labels, separated

	by spaces, to the file or cleared by writing "-" to the file.



If you are using the smackload utility

you can add access rules in /etc/smack/accesses. They take the form:

Documentation/security/keys.txt

+25 −16
Original line number Diff line number Diff line
@@ -1049,12 +1049,12 @@ search a specific keyring, so using keyrings in this way is of limited utility. 
NOTES ON ACCESSING PAYLOAD CONTENTS

===================================



The simplest payload is just a number in key->payload.value. In this case,

there's no need to indulge in RCU or locking when accessing the payload.

The simplest payload is just data stored in key->payload directly.  In this

case, there's no need to indulge in RCU or locking when accessing the payload.



More complex payload contents must be allocated and a pointer to them set in

key->payload.data. One of the following ways must be selected to access the

data:

More complex payload contents must be allocated and pointers to them set in the

key->payload.data[] array.  One of the following ways must be selected to

access the data:



 (1) Unmodifiable key type.
@@ -1092,6 +1092,13 @@ data: 
     the payload. key->datalen cannot be relied upon to be consistent with the

     payload just dereferenced if the key's semaphore is not held.



     Note that key->payload.data[0] has a shadow that is marked for __rcu

     usage.  This is called key->payload.rcu_data0.  The following accessors

     wrap the RCU calls to this element:



	rcu_assign_keypointer(struct key *key, void *data);

	void *rcu_dereference_key(struct key *key);





===================

DEFINING A KEY TYPE
@@ -1143,8 +1150,7 @@ The structure has a number of fields, some of which are mandatory: 


	struct key_preparsed_payload {

		char		*description;

		void		*type_data[2];

		void		*payload;

		union key_payload payload;

		const void	*data;

		size_t		datalen;

		size_t		quotalen;
@@ -1160,10 +1166,9 @@ The structure has a number of fields, some of which are mandatory: 
     attached as a string to the description field.  This will be used for the

     key description if the caller of add_key() passes NULL or "".



     The method can attach anything it likes to type_data[] and payload.  These

     are merely passed along to the instantiate() or update() operations.  If

     set, the expiry time will be applied to the key if it is instantiated from

     this data.

     The method can attach anything it likes to payload.  This is merely passed

     along to the instantiate() or update() operations.  If set, the expiry

     time will be applied to the key if it is instantiated from this data.



     The method should return 0 if successful or a negative error code

     otherwise.
@@ -1172,11 +1177,10 @@ The structure has a number of fields, some of which are mandatory: 
 (*) void (*free_preparse)(struct key_preparsed_payload *prep);



     This method is only required if the preparse() method is provided,

     otherwise it is unused.  It cleans up anything attached to the

     description, type_data and payload fields of the key_preparsed_payload

     struct as filled in by the preparse() method.  It will always be called

     after preparse() returns successfully, even if instantiate() or update()

     succeed.

     otherwise it is unused.  It cleans up anything attached to the description

     and payload fields of the key_preparsed_payload struct as filled in by the

     preparse() method.  It will always be called after preparse() returns

     successfully, even if instantiate() or update() succeed.





 (*) int (*instantiate)(struct key *key, struct key_preparsed_payload *prep);
@@ -1197,6 +1201,11 @@ The structure has a number of fields, some of which are mandatory: 


     It is safe to sleep in this method.



     generic_key_instantiate() is provided to simply copy the data from

     prep->payload.data[] to key->payload.data[], with RCU-safe assignment on

     the first element.  It will then clear prep->payload.data[] so that the

     free_preparse method doesn't release the data.





 (*) int (*update)(struct key *key, const void *data, size_t datalen);

MAINTAINERS

+1 −0
Original line number Diff line number Diff line
@@ -10738,6 +10738,7 @@ F: drivers/media/pci/tw68/ 
TPM DEVICE DRIVER

M:	Peter Huewe <peterhuewe@gmx.de>

M:	Marcel Selhorst <tpmdd@selhorst.net>

M:	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>

R:	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>

W:	http://tpmdd.sourceforge.net

L:	tpmdd-devel@lists.sourceforge.net (moderated for non-subscribers)

CRA Git | Maintained and supported by SUSTech CRA and CCSE