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

* STMicroelectronics SAS. ST33ZP24 TPM SoC

Required properties:

- compatible: Should be "st,st33zp24-spi".

- spi-max-frequency: Maximum SPI frequency (<= 10000000).

Optional ST33ZP24 Properties:

- interrupt-parent: phandle for the interrupt gpio controller

- interrupts: GPIO interrupt to which the chip is connected

- lpcpd-gpios: Output GPIO pin used for ST33ZP24 power management D1/D2 state.

If set, power must be present when the platform is going into sleep/hibernate mode.

Optional SoC Specific Properties:

- pinctrl-names: Contains only one value - "default".

- pintctrl-0: Specifies the pin control groups used for this controller.

Example (for ARM-based BeagleBoard xM with ST33ZP24 on SPI4):

&mcspi4 {

        status = "okay";

        st33zp24@0 {

                compatible = "st,st33zp24-spi";

                spi-max-frequency = <10000000>;

                interrupt-parent = <&gpio5>;

                interrupts = <7 IRQ_TYPE_LEVEL_HIGH>;

                lpcpd-gpios = <&gpio5 15 GPIO_ACTIVE_HIGH>;

        };

};

	git://github.com/smack-team/smack.git

This should make and install on most modern distributions.

There are three commands included in smackutil:

There are five commands included in smackutil:

smackload  - properly formats data for writing to /smack/load

smackcipso - properly formats data for writing to /smack/cipso

chsmack    - display or set Smack extended attribute values

smackctl   - load the Smack access rules

smackaccess - report if a process with one label has access

              to an object with another

These two commands are obsolete with the introduction of

the smackfs/load2 and smackfs/cipso2 interfaces.

smackload  - properly formats data for writing to smackfs/load

smackcipso - properly formats data for writing to smackfs/cipso

In keeping with the intent of Smack, configuration data is

minimal and not strictly required. The most important

Add this line to /etc/fstab:

    smackfs /smack smackfs smackfsdef=* 0 0

    smackfs /sys/fs/smackfs smackfs defaults 0 0

and create the /smack directory for mounting.

The /sys/fs/smackfs directory is created by the kernel.

Smack uses extended attributes (xattrs) to store labels on filesystem

objects. The attributes are stored in the extended attribute security

    # attr -S -s SMACK64 -V "value" path

    # chsmack -a value path

A process can see the smack label it is running with by

A process can see the Smack label it is running with by

reading /proc/self/attr/current. A process with CAP_MAC_ADMIN

can set the process smack by writing there.

can set the process Smack by writing there.

Most Smack configuration is accomplished by writing to files

in the smackfs filesystem. This pseudo-filesystem is usually

mounted on /smack.

in the smackfs filesystem. This pseudo-filesystem is mounted

on /sys/fs/smackfs.

access

	This interface reports whether a subject with the specified

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

ptrace

	This is used to define the current ptrace policy

	0 - default: this is the policy that relies on smack access rules.

	0 - default: this is the policy that relies on Smack access rules.

	    For the PTRACE_READ a subject needs to have a read access on

	    object. For the PTRACE_ATTACH a read-write access is required.

	1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is

	    only allowed when subject's and object's labels are equal.

	    PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE.

	    PTRACE_READ is not affected. Can be overridden with CAP_SYS_PTRACE.

	2 - draconian: this policy behaves like the 'exact' above with an

	    exception that it can't be overriden with CAP_SYS_PTRACE.

	    exception that it can't be overridden with CAP_SYS_PTRACE.

revoke-subject

	Writing a Smack label here sets the access to '-' for all access

	rules with that subject label.

unconfined

	If the kernel is configured with CONFIG_SECURITY_SMACK_BRINGUP

	a process with CAP_MAC_ADMIN can write a label into this interface.

	Thereafter, accesses that involve that label will be logged and

	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.

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

    subjectlabel objectlabel access

access is a combination of the letters rwxa which specify the

access is a combination of the letters rwxatb which specify the

kind of access permitted a subject with subjectlabel on an

object with objectlabel. If there is no rule no access is allowed.

Labels

Smack labels are ASCII character strings, one to twenty-three characters in

length. Single character labels using special characters, that being anything

Smack labels are ASCII character strings. They can be up to 255 characters

long, but keeping them to twenty-three characters is recommended.

Single character labels using special characters, that being anything

other than a letter or digit, are reserved for use by the Smack development

team. Smack labels are unstructured, case sensitive, and the only operation

ever performed on them is comparison for equality. Smack labels cannot

	? 	Pronounced "huh", a single question mark character.

	@ 	Pronounced "web", a single at sign character.

Every task on a Smack system is assigned a label. System tasks, such as

init(8) and systems daemons, are run with the floor ("_") label. User tasks

are assigned labels according to the specification found in the

/etc/smack/user configuration file.

Every task on a Smack system is assigned a label. The Smack label

of a process will usually be assigned by the system initialization

mechanism.

Access Rules

	w: indicates that write access should be granted.

	x: indicates that execute access should be granted.

	t: indicates that the rule requests transmutation.

	b: indicates that the rule should be reported for bring-up.

Uppercase values for the specification letters are allowed as well.

Access mode specifications can be in any order. Examples of acceptable rules

	Secret    Unclass R

	Manager   Game    x

	User      HR      w

	Snap      Crackle rwxatb

	New       Old     rRrRr

	Closed    Off     -

Spaces are not allowed in labels. Since a subject always has access to files

with the same label specifying a rule for that case is pointless. Only

valid letters (rwxatRWXAT) and the dash ('-') character are allowed in

valid letters (rwxatbRWXATB) and the dash ('-') character are allowed in

access specifications. The dash is a placeholder, so "a-r" is the same

as "ar". A lone dash is used to specify that no access should be allowed.

Setting Access Rules

The configuration file /etc/smack/accesses contains the rules to be set at

system startup. The contents are written to the special file /smack/load.

Rules can be written to /smack/load at any time and take effect immediately.

For any pair of subject and object labels there can be only one rule, with the

most recently specified overriding any earlier specification.

The program smackload is provided to ensure data is formatted

properly when written to /smack/load. This program reads lines

of the form

    subjectlabel objectlabel mode.

system startup. The contents are written to the special file

/sys/fs/smackfs/load2. Rules can be added at any time and take effect

immediately. For any pair of subject and object labels there can be only

one rule, with the most recently specified overriding any earlier

specification.

Task Attribute

Privilege

A process with CAP_MAC_OVERRIDE is privileged.

A process with CAP_MAC_OVERRIDE or CAP_MAC_ADMIN is privileged.

CAP_MAC_OVERRIDE allows the process access to objects it would

be denied otherwise. CAP_MAC_ADMIN allows a process to change

Smack data, including rules and attributes.

Smack Networking

ambient label.

Smack requires configuration in the case where packets from a system that is

not smack that speaks CIPSO may be encountered. Usually this will be a Trusted

not Smack that speaks CIPSO may be encountered. Usually this will be a Trusted

Solaris system, but there are other, less widely deployed systems out there.

CIPSO provides 3 important values, a Domain Of Interpretation (DOI), a level,

and a category set with each packet. The DOI is intended to identify a group

of systems that use compatible labeling schemes, and the DOI specified on the

smack system must match that of the remote system or packets will be

discarded. The DOI is 3 by default. The value can be read from /smack/doi and

can be changed by writing to /smack/doi.

Smack system must match that of the remote system or packets will be

discarded. The DOI is 3 by default. The value can be read from

/sys/fs/smackfs/doi and can be changed by writing to /sys/fs/smackfs/doi.

The label and category set are mapped to a Smack label as defined in

/etc/smack/cipso.

meaning.

The mapping of Smack labels to CIPSO values is defined by writing to

/smack/cipso. Again, the format of data written to this special file

is highly restrictive, so the program smackcipso is provided to

ensure the writes are done properly. This program takes mappings

on the standard input and sends them to /smack/cipso properly.

/sys/fs/smackfs/cipso2.

In addition to explicit mappings Smack supports direct CIPSO mappings. One

CIPSO level is used to indicate that the category set passed in the packet is

in fact an encoding of the Smack label. The level used is 250 by default. The

value can be read from /smack/direct and changed by writing to /smack/direct.

value can be read from /sys/fs/smackfs/direct and changed by writing to

/sys/fs/smackfs/direct.

Socket Attributes

Smack Netlabel Exceptions

You will often find that your labeled application has to talk to the outside,

unlabeled world. To do this there's a special file /smack/netlabel where you can

add some exceptions in the form of :

unlabeled world. To do this there's a special file /sys/fs/smackfs/netlabel

where you can add some exceptions in the form of :

@IP1	   LABEL1 or

@IP2/MASK  LABEL2

write access on LABEL1, and access to the subnet @IP2/MASK if it has write

access on LABEL2.

Entries in the /smack/netlabel file are matched by longest mask first, like in

classless IPv4 routing.

Entries in the /sys/fs/smackfs/netlabel file are matched by longest mask

first, like in classless IPv4 routing.

A special label '@' and an option '-CIPSO' can be used there :

@      means Internet, any application with any label has access to it

-CIPSO means standard CIPSO networking

If you don't know what CIPSO is and don't plan to use it, you can just do :

echo 127.0.0.1 -CIPSO > /smack/netlabel

echo 0.0.0.0/0 @      > /smack/netlabel

echo 127.0.0.1 -CIPSO > /sys/fs/smackfs/netlabel

echo 0.0.0.0/0 @      > /sys/fs/smackfs/netlabel

If you use CIPSO on your 192.168.0.0/16 local network and need also unlabeled

Internet access, you can have :

echo 127.0.0.1      -CIPSO > /smack/netlabel

echo 192.168.0.0/16 -CIPSO > /smack/netlabel

echo 0.0.0.0/0      @      > /smack/netlabel

echo 127.0.0.1      -CIPSO > /sys/fs/smackfs/netlabel

echo 192.168.0.0/16 -CIPSO > /sys/fs/smackfs/netlabel

echo 0.0.0.0/0      @      > /sys/fs/smackfs/netlabel

Writing Applications for Smack

If you want Smack auditing of security events, you need to set CONFIG_AUDIT

in your kernel configuration.

By default, all denied events will be audited. You can change this behavior by

writing a single character to the /smack/logging file :

writing a single character to the /sys/fs/smackfs/logging file :

0 : no logging

1 : log denied (default)

2 : log accepted

the subject, the object, the rights requested, the action, the kernel function

that triggered the event, plus other pairs depending on the type of event

audited.

Bringup Mode

Bringup mode provides logging features that can make application

configuration and system bringup easier. Configure the kernel with

CONFIG_SECURITY_SMACK_BRINGUP to enable these features. When bringup

mode is enabled accesses that succeed due to rules marked with the "b"

access mode will logged. When a new label is introduced for processes

rules can be added aggressively, marked with the "b". The logging allows

tracking of which rules actual get used for that label.

Another feature of bringup mode is the "unconfined" option. Writing

a label to /sys/fs/smackfs/unconfined makes subjects with that label

able to access any object, and objects with that label accessible to

all subjects. Any access that is granted because a label is unconfined

is logged. This feature is dangerous, as files and directories may

be created in places they couldn't if the policy were being enforced.

TPM DEVICE DRIVER

M:	Peter Huewe <peterhuewe@gmx.de>

M:	Marcel Selhorst <tpmdd@selhorst.net>

R:	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>

W:	http://tpmdd.sourceforge.net

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

Q:	git git://github.com/PeterHuewe/linux-tpmdd.git

if TCG_TPM

config TCG_TIS

	tristate "TPM Interface Specification 1.2 Interface"

	tristate "TPM Interface Specification 1.2 Interface / TPM 2.0 FIFO Interface"

	depends on X86

	---help---

	  If you have a TPM security chip that is compliant with the

	  TCG TIS 1.2 TPM specification say Yes and it will be accessible

	  from within Linux.  To compile this driver as a module, choose

	  M here; the module will be called tpm_tis.

	  TCG TIS 1.2 TPM specification (TPM1.2) or the TCG PTP FIFO

	  specification (TPM2.0) say Yes and it will be accessible from

	  within Linux. To compile this driver as a module, choose  M here;

	  the module will be called tpm_tis.

config TCG_TIS_I2C_ATMEL

	tristate "TPM Interface Specification 1.2 Interface (I2C - Atmel)"

	  will be accessible from within Linux.  To compile this driver

	  as a module, choose M here; the module will be called tpm_ibmvtpm.

config TCG_TIS_I2C_ST33

	tristate "TPM Interface Specification 1.2 Interface (I2C - STMicroelectronics)"

	depends on I2C

	depends on GPIOLIB

	---help---

	  If you have a TPM security chip from STMicroelectronics working with

	  an I2C bus say Yes and it will be accessible from within Linux.

	  To compile this driver as a module, choose M here; the module will be

	  called tpm_i2c_stm_st33.

config TCG_XEN

	tristate "XEN TPM Interface"

	depends on TCG_TPM && XEN

	  from within Linux.  To compile this driver as a module, choose

	  M here; the module will be called tpm_crb.

source "drivers/char/tpm/st33zp24/Kconfig"

endif # TCG_TPM

obj-$(CONFIG_TCG_ATMEL) += tpm_atmel.o

obj-$(CONFIG_TCG_INFINEON) += tpm_infineon.o

obj-$(CONFIG_TCG_IBMVTPM) += tpm_ibmvtpm.o

obj-$(CONFIG_TCG_TIS_I2C_ST33) += tpm_i2c_stm_st33.o

obj-$(CONFIG_TCG_TIS_ST33ZP24) += st33zp24/

obj-$(CONFIG_TCG_XEN) += xen-tpmfront.o

obj-$(CONFIG_TCG_CRB) += tpm_crb.o