[GIT PULL] Security subsystem update for 4.4

[James Morris]

Please pull.

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.

The following changes since commit 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c:

  Merge tag 'regmap-v4.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap (2015-11-02 
16:16:24 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

Arnd Bergmann (1):
  apparmor: clarify CRYPTO dependency

David Howells (3):
  KEYS: Provide a script to extract the sys cert list from a vmlinux file
  KEYS: Provide a script to extract a module signature
  KEYS: Merge the type-specific data with the payload data

Dmitry Kasatkin (1):
  integrity: prevent loading untrusted certificates on the IMA trusted 
keyring

Geert Uytterhoeven (1):
  tpm: Allow compile test of GPIO consumers if !GPIOLIB

Geliang Tang (3):
  smack: smk_ipv6_port_list should be static
  KEYS: use kvfree() in add_key
  selinux: ioctl_has_perm should be static

Hon Ching \(Vicky\) Lo (6):
  vTPM: fix memory allocation flag for rtce buffer at kernel boot
  vTPM: fix searching for the right vTPM node in device tree
  vTPM: reformat event log to be byte-aligned
  vTPM: get the buffer allocated for event log instead of the actual log
  vTPM: support little endian guests
  TPM: remove unnecessary little endian conversion

Insu Yun (1):
  keys: Be more consistent in selection of union members used

James Morris (4):
  Merge branch 'next' of git://git.kernel.org/.../zohar/linux-integrity 
into next
  Merge branch 'smack-for-4.4' of https://github.com/cschaufler/smack-next 
into next
  Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/selinux 
into next
  Merge tag 'keys-next-20151021' of 
git://git.kernel.org/.../dhowells/linux-fs into next

Jarkko Sakkinen (10):
  tpm, tpm_crb: fix unaligned read of the command buffer address
  tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
  sysfs: added __compat_only_sysfs_link_entry_to_kobj()
  tpm: move the PPI attributes to character device directory.
  tpm: update PPI documentation to address the location change.
  tpm: introduce tpm_buf
  keys, trusted: move struct trusted_key_options to trusted-type.h
  tpm: seal/unseal for TPM 2.0
  keys, trusted: seal/unseal with TPM 2.0 chips
  MAINTAINERS: add new maintainer for TPM DEVICE DRIVER

Jeff Vander Stoep (1):
  selinux: do not check open perm on ftruncate call

José Bollo (1):
  Smack: Minor initialisation improvement

Krzysztof Kozlowski (1):
  char: Drop owner assignment from i2c_driver

Lukasz Pawelczyk (1):
  Smack: fix a NULL dereference in wrong smack_import_entry() usage

Paul Gortmaker (1):
  certs: add .gitignore to stop git nagging about x509_certificate_list

Paul Moore (1):
  selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default

Rasmus Villemoes (5):
  selinux: introduce security_context_str_to_sid
  selinux: remove pointless cast in selinux_inode_setsecurity()
  selinux: use kmemdup in security_sid_to_context_core()
  selinux: use kstrdup() in security_get_bools()
  selinux: use sprintf return value

Roman Kubiak (1):
  Smack: pipefs fix in smack_d_instantiate

Sangwoo (1):
  selinux: Use a kmem_cache for allocation struct file_security_struct

Zbigniew Jasinski (1):
  Smack: limited capability for changing process label

 Documentation/ABI/testing/sysfs-driver-ppi   |   19 +-
 Documentation/crypto/asymmetric-keys.txt |   27 ++--
 Documentation/security/Smack.txt |   10 +
 Documentation/security/keys.txt  |   41 +++--
 MAINTAINERS  |1 +
 arch/powerpc/kernel/prom_init.c  |   40 +++-
 certs/.gitignore |4 +
 crypto/asymmetric_keys/asymmetric_keys.h |5 -
 crypto/asymmetric_keys/asymmetric_type.c |   44 +++--
 crypto/asymmetric_keys/public_key.c  |4 +-
 crypto/asymmetric_keys/signature.c   |2 +-
 crypto/asymmetric_keys/x509_parser.h |1 +
 crypto/asymmetric_keys/x509_public_key.c |9 +-
 drivers/char/tpm/st33zp24/Kconfig|2 +-
 drivers/char/tpm/st33zp24/i2c.c  |1 -
 drivers/char/tpm/tpm-chip.c  |   24 ++-
 drivers/char/tpm/tpm-interface.c |   76 +++
 drivers/char/tpm/tpm.h   |  134 +++-
 drivers/char/tpm/tpm2-cmd.c  |  250 +-
 drivers/char/tpm/tpm_crb.c   |   39 ++--
 drivers/char/tpm/tpm_eventlog.c  |   78 +--
 drivers/char/tpm/tpm_eventlog.h  |6 +
 drivers/char/tpm/tpm_i2c_atmel.c 

Re: [PATCH v2 1/3] keys, trusted: select the hash algorithm

[Mimi Zohar]

On Tue, 2015-11-03 at 09:39 +0200, Jarkko Sakkinen wrote:
> On Mon, Nov 02, 2015 at 07:16:49AM -0500, Mimi Zohar wrote:
> > On Fri, 2015-10-30 at 13:35 +0200, Jarkko Sakkinen wrote:
> > 
> > > @@ -787,6 +791,20 @@ static int getoptions(char *c, struct 
> > > trusted_key_payload *pay,
> > >   return -EINVAL;
> > >   opt->pcrlock = lock;
> > >   break;
> > > + case Opt_hash:
> > > + for (i = 0; i < HASH_ALGO__LAST; i++) {
> > > + if (!strcmp(args[0].from, hash_algo_name[i])) {
> > > + opt->hash = i;
> > > + break;
> > > + }
> > > + }
> > > + res = tpm_is_tpm2(TPM_ANY_NUM);
> > 
> > While looking at this, I wanted to verify that chips are still added to
> > the tail of the tpm_chip_list.  Unfortunately, commit "afb5abc tpm:
> > two-phase chip management functions" reverted David Howell's commit
> > "770ab65 TPM: Add new TPMs to the tail of the list to prevent
> > inadvertent change of dev".
> > 
> > > + if (res < 0)
> > > + return res;
> > > + if (i == HASH_ALGO__LAST ||
> > > + (!res && i != HASH_ALGO_SHA1))
> > > + return -EINVAL;
> > > + break;
> > 
> > If the first TPM registered is a TPM 1.2, then changing the default TPM
> > 2.0 hash algorithm will fail.
> 
> Now that we are going fix this issue in 4.3 and 4.4 do you find this
> patch otherwise acceptable?
> 
> PS. In other options that we don't support in TPM2 I'm planning to
> submit a fix that they will return -EINVAL (like pcrinfo).

I don't have a problem failing the request, but I do suggest adding some
sort of error message.  Different systems might behavior differently
without any explanation.

Mimi

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RFC rdma cgroup

[Parav Pandit]

>> Resource are defined as index and as match_table_t.
>>
>> enum rdma_resource_type {
>> RDMA_VERB_RESOURCE_UCTX,
>> RDMA_VERB_RESOURCE_AH,
>> RDMA_VERB_RESOURCE_PD,
>> RDMA_VERB_RESOURCE_CQ,
>> RDMA_VERB_RESOURCE_MR,
>> RDMA_VERB_RESOURCE_MW,
>> RDMA_VERB_RESOURCE_SRQ,
>> RDMA_VERB_RESOURCE_QP,
>> RDMA_VERB_RESOURCE_FLOW,
>> RDMA_VERB_RESOURCE_MAX,
>> };
>> So UAPI RDMA resources can evolve by just adding more entries here.
> Are the names that appear in userspace also controlled by uverbs? What
> about the vendor specific resources?

I am not sure I followed your question.
Basically any RDMA resource that is allocated through uverb API can be tracked.
uverb makes the call to charge/uncharge.
There is list rdma.resources.verbs.list. This file lists all the verbs
resource names of all the devices which have registered themselves to
rdma cgroup.
Similarly there is rdma.resource.hw.list. This file lists all hw
specific resource names, which means they are defined run time and
potentially different for each vendor.

So it looks like below,
#cat rdma.resources.verbs.list
Output:
mlx4_0 uctx ah pd cq mr mw srq qp flow
mlx4_1 uctx ah pd cq mr mw srq qp flow rss_wq

#cat rdma.resources.hw.list
hfi1 hw_qp hw_mr sw_pd
(This particular one is hypothical example, I haven't actually coded
this, unlike uverbs which is real).

 (c) When process migrate from one to other cgroup, resource is
 continue to be owned by the creator cgroup (rather css).
 After process migration, whenever new resource is created in new
 cgroup, it will be owned by new cgroup.
>>> It sounds a little different from how other cgroups behave. I agree that
>>> mostly processes will create the resources in their cgroup and won't
>>> migrate, but why not move the charge during migration?
>>>
>> With fork() process doesn't really own the resource (unlike other file
>> and socket descriptors).
>> Parent process might have died also.
>> There is possibly no clear way to transfer resource to right child.
>> Child that cgroup picks might not even want to own RDMA resources.
>> RDMA resources might be allocated by one process and freed by other
>> process (though this might not be the way they use it).
>> Its pretty similar to other cgroups with exception in migration area,
>> such exception comes from different behavior of how RDMA resources are
>> owned, created and used.
>> Recent unified hierarchy patch from Tejun equally highlights to not
>> frequently migrate processes among cgroups.
>>
>> So in current implementation, (like other),
>> if process created a RDMA resource, forked a child.
>> child and parent both can allocate and free more resources.
>> child moved to different cgroup. But resource is shared among them.
>> child can free also the resource. All crazy combinations are possible
>> in theory (without much use cases).
>> So at best they are charged to the first cgroup css in which
>> parent/child are created and reference is hold to CSS.
>> cgroup, process can die, cut css remains until RDMA resources are freed.
>> This is similar to process behavior where task struct is release but
>> id is hold up for a while.
>
> I guess there aren't a lot of options when the resources can belong to
> multiple cgroups. So after migrating, new resources will belong to the
> new cgroup or the old one?
Resource always belongs to the cgroup in which its created, regardless
of process migration.
Again, its owned at the css level instead of cgroup. Therefore
original cgroup can also be deleted but internal reference to data
structure and that is freed and last rdma resource is freed.

>
> When I was talking about limiting to MAC/VLAN pairs I only meant
> limiting an RDMA device's ability to use that pair (e.g. use a GID that
> uses the specific MAC VLAN pair). I don't understand how that makes the
> RDMA cgroup any more generic than it is.
>
Oh ok. That doesn't. I meant that I wanted to limit how many vlans a
given container can create.
We have just high level capabilities (7) to enable such creation, but
not the count.

>>  or
>>> only a subset of P_Keys and GIDs it has. Do you see such limitations
>>> also as part of this cgroup?
>>>
>> At present no. Because GID, P_key resources are created from the
>> bottom up, either by stack or by network. They are kind of not tied to
>> the user processes, unlike mac, vlan, qp which are more application
>> driven or administrative driven.
> They are created from the network, after the network administrator
> configured them this way.
>
>> For applications that doesn't use RDMA-CM, query_device and query_port
>> will filter out the GID entries based on the network namespace in
>> which caller process is running.
> This could work well for RoCE, as each entry in the GID table is
> associated with a net device and a network namespace. However, in
> InfiniBand, the GID table isn't directly related to the network
> namespace. As 

[PATCH v3] capabilities.7, prctl.2: Document ambient capabilities

[Andy Lutomirski]

Reviewed-by: Kees Cook 
Signed-off-by: Andy Lutomirski 
---

Changes from v2: Add a note about arg3 == 0 in CLEAR_ALL.

man2/prctl.2| 13 +
 man7/capabilities.7 | 40 ++--
 2 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/man2/prctl.2 b/man2/prctl.2
index e743a6305969..bf8680f3b62d 100644
--- a/man2/prctl.2
+++ b/man2/prctl.2
@@ -954,6 +954,19 @@ had been called.
 For further information on Intel MPX, see the kernel source file
 .IR Documentation/x86/intel_mpx.txt .
 .\"
+.TP
+.BR PR_CAP_AMBIENT " (since Linux 4.2)"
+Reads or changes the ambient capability set.  If arg2 is PR_CAP_AMBIENT_RAISE,
+then the capability specified in arg3 is added to the ambient set.  This will
+fail, returning EPERM, if the capability is not already both permitted and
+inheritable or if the SECBIT_NO_CAP_AMBIENT_RAISE securebit is set.  If arg2
+is PR_CAP_AMBIENT_LOWER, then the capability specified in arg3 is removed
+from the ambient set.  If arg2 is PR_CAP_AMBIENT_IS_SET, then
+.BR prctl (2)
+will return 1 if the capability in arg3 is in the ambient set and 0 if not.
+If arg2 is PR_CAP_AMBIENT_CLEAR_ALL, then all capabilities will
+be removed from the ambient set.  (Using PR_CAP_AMBIENT_CLEAR_ALL requires
+setting arg3 to zero.)
 .SH RETURN VALUE
 On success,
 .BR PR_GET_DUMPABLE ,
diff --git a/man7/capabilities.7 b/man7/capabilities.7
index 616189c881e4..8934d05a5b07 100644
--- a/man7/capabilities.7
+++ b/man7/capabilities.7
@@ -700,13 +700,34 @@ a program whose associated file capabilities grant that 
capability).
 .IR Inheritable :
 This is a set of capabilities preserved across an
 .BR execve (2).
-It provides a mechanism for a process to assign capabilities
-to the permitted set of the new program during an
-.BR execve (2).
+Inheritable capabilities remain inheritable when executing any program,
+and inheritable capabilities are added to the permitted set when executing
+a program that has the corresponding bits set in the file inheritable set.
+.IP
+Because inheritable capabilities are not generally preserved across
+.BR execve (2)
+when running as a non-root user, applications that wish to run helper
+programs with elevated capabilities should consider using ambient capabilities,
+described below.
 .TP
 .IR Effective :
 This is the set of capabilities used by the kernel to
 perform permission checks for the thread.
+.TP
+.IR Ambient " (since Linux 4.3):"
+This is a set of capabilities that are preserved across an
+.BR execve (2)
+of a program that does not have file capabilities.  The ambient capability
+set obeys the invariant that no capability can ever be ambient if it is
+not both permitted and inheritable.  Ambient capabilities are
+preserved in the permitted set and added to the effective
+set when
+.BR execve (2)
+is called.  The ambient capability set is modified using
+.BR prctl (2).
+Executing a program that changes uid or gid due to the setuid or setgid
+bits or executing a program that has any file capabilities set will clear
+the ambient set.
 .PP
 A child created via
 .BR fork (2)
@@ -788,10 +809,12 @@ the process using the following algorithm:
 .in +4n
 .nf
 
+P'(ambient) = (file has capabilities or is setuid or setgid) ? 0 : P(ambient)
+
 P'(permitted) = (P(inheritable) & F(inheritable)) |
-(F(permitted) & cap_bset)
+(F(permitted) & cap_bset) | P'(ambient)
 
-P'(effective) = F(effective) ? P'(permitted) : 0
+P'(effective) = F(effective) ? P'(permitted) : P'(ambient)
 
 P'(inheritable) = P(inheritable)[i.e., unchanged]
 
@@ -1074,6 +1097,10 @@ an effective or real UID of 0 calls
 .BR execve (2).
 (See the subsection
 .IR "Capabilities and execution of programs by root" .)
+.TP
+.B SECBIT_NO_CAP_AMBIENT_RAISE
+Setting this flag disallows
+.BR PR_CAP_AMBIENT_RAISE .
 .PP
 Each of the above "base" flags has a companion "locked" flag.
 Setting any of the "locked" flags is irreversible,
@@ -1082,8 +1109,9 @@ corresponding "base" flag.
 The locked flags are:
 .BR SECBIT_KEEP_CAPS_LOCKED ,
 .BR SECBIT_NO_SETUID_FIXUP_LOCKED ,
+.BR SECBIT_NOROOT_LOCKED ,
 and
-.BR SECBIT_NOROOT_LOCKED .
+.BR SECBIT_NO_CAP_AMBIENT_RAISE .
 .PP
 The
 .I securebits
-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe 
linux-security-module" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html