* [GIT] Security subsystem updates for 3.13
@ 2013-11-07 0:51 James Morris
2013-11-18 15:31 ` Josh Boyer
0 siblings, 1 reply; 14+ messages in thread
From: James Morris @ 2013-11-07 0:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-security-module
In this patchset, we finally get an SELinux update, with Paul Moore taking
over as maintainer of that code.
Also a significant update for the Keys subsystem, as well as maintenance
updates to Smack, IMA, TPM, and Apparmor.
Please pull.
The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus
Anand Avati (1):
selinux: consider filesystem subtype in policies
Antonio Alecrim Jr (1):
X.509: remove possible code fragility: enumeration values not handled
Casey Schaufler (2):
Smack: Implement lock security mode
Smack: Ptrace access check mode
Chen Gang (1):
kernel/system_certificate.S: use real contents instead of macro GLOBAL()
Chris PeBenito (1):
Add SELinux policy capability for always checking packet and peer classes.
David Howells (29):
KEYS: Skip key state checks when checking for possession
KEYS: Use bool in make_key_ref() and is_key_possessed()
KEYS: key_is_dead() should take a const key pointer argument
KEYS: Consolidate the concept of an 'index key' for key access
KEYS: Introduce a search context structure
KEYS: Search for auth-key by name rather than target key ID
KEYS: Define a __key_get() wrapper to use rather than atomic_inc()
KEYS: Drop the permissions argument from __keyring_search_one()
Add a generic associative array implementation.
KEYS: Expand the capacity of a keyring
KEYS: Implement a big key type that can save to tmpfs
KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches
KEYS: Rename public key parameter name arrays
KEYS: Move the algorithm pointer array from x509 to public_key.c
KEYS: Store public key algo ID in public_key struct
KEYS: Split public_key_verify_signature() and make available
KEYS: Store public key algo ID in public_key_signature struct
X.509: struct x509_certificate needs struct tm declaring
X.509: Embed public_key_signature struct and create filler function
X.509: Check the algorithm IDs obtained from parsing an X.509 certificate
X.509: Handle certificates that lack an authorityKeyIdentifier field
X.509: Remove certificate date checks
KEYS: Load *.x509 files into kernel keyring
KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate
KEYS: Separate the kernel signature checking keyring from module signing
KEYS: Add a 'trusted' flag and a 'trusted only' flag
KEYS: Set the asymmetric-key type default search method
KEYS: Fix a race between negating a key and reading the error set
KEYS: Fix keyring quota misaccounting on key replacement and unlink
Dmitry Kasatkin (11):
ima: fix script messages
crypto: provide single place for hash algo information
keys: change asymmetric keys to use common hash definitions
ima: provide support for arbitrary hash algorithms
ima: read and use signature hash algorithm
ima: pass full xattr with the signature
ima: use dynamically allocated hash storage
ima: provide dedicated hash algo allocation function
ima: support arbitrary hash algorithms in ima_calc_buffer_hash
ima: ima_calc_boot_agregate must use SHA1
ima: provide hash algo info in the xattr
Duan Jiong (1):
selinux: Use kmemdup instead of kmalloc + memcpy
Eric Paris (13):
SELinux: fix selinuxfs policy file on big endian systems
SELinux: remove crazy contortions around proc
SELinux: make it harder to get the number of mnt opts wrong
SELinux: use define for number of bits in the mnt flags mask
SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT
SELinux: do all flags twiddling in one place
SELinux: renumber the superblock options
SELinux: change sbsec->behavior to short
SELinux: do not handle seclabel as a special flag
SELinux: pass a superblock to security_fs_use
SELinux: use a helper function to determine seclabel
Revert "SELinux: do not handle seclabel as a special flag"
security: remove erroneous comment about capabilities.o link ordering
James Morris (3):
Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next
Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next
Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next
Jason Gunthorpe (11):
tpm: ibmvtpm: Use %zd formatting for size_t format arguments
tpm atmel: Call request_region with the correct base
tpm: Store devname in the tpm_chip
tpm: Use container_of to locate the tpm_chip in tpm_open
tpm: Remove redundant dev_set_drvdata
tpm: st33: Remove chip->data_buffer access from this driver
tpm: Remove tpm_show_caps_1_2
tpm: Rename tpm.c to tpm-interface.c
tpm: Merge the tpm-bios module with tpm.o
tpm: Add support for the Nuvoton NPCT501 I2C TPM
tpm: Add support for Atmel I2C TPMs
John Johansen (3):
apparmor: fix capability to not use the current task, during reporting
apparmor: remove tsk field from the apparmor_audit_struct
apparmor: remove parent task info from audit logging
Josh Boyer (1):
KEYS: Make BIG_KEYS boolean
Konstantin Khlebnikov (2):
MPILIB: add module description and license
X.509: add module description and license
Mimi Zohar (10):
KEYS: Make the system 'trusted' keyring viewable by userspace
KEYS: verify a certificate is signed by a 'trusted' key
KEYS: initialize root uid and session keyrings early
Revert "ima: policy for RAMFS"
ima: differentiate between template hash and file data hash sizes
ima: add audit log support for larger hashes
ima: add Kconfig default measurement list template
ima: enable support for larger default filedata hash algorithms
ima: extend the measurement list to include the file signature
ima: define '_ima' as a builtin 'trusted' keyring
Oleg Nesterov (1):
apparmor: remove the "task" arg from may_change_ptraced_domain()
Paul Moore (13):
lsm: split the xfrm_state_alloc_security() hook implementation
selinux: cleanup and consolidate the XFRM alloc/clone/delete/free code
selinux: cleanup selinux_xfrm_policy_lookup() and selinux_xfrm_state_pol_flow_match()
selinux: cleanup selinux_xfrm_sock_rcv_skb() and selinux_xfrm_postroute_last()
selinux: cleanup some comment and whitespace issues in the XFRM code
selinux: cleanup selinux_xfrm_decode_session()
selinux: cleanup the XFRM header
selinux: remove the BUG_ON() from selinux_skb_xfrm_sid()
selinux: fix problems in netnode when BUG() is compiled out
Merge git://git.infradead.org/users/eparis/selinux
selinux: add Paul Moore as a SELinux maintainer
selinux: add Paul Moore as a SELinux maintainer
selinux: correct locking in selinux_netlbl_socket_connect)
Peter Huewe (4):
tpm: MAINTAINERS: Add myself as tpm maintainer
tpm: cleanup checkpatch warnings
tpm: Fix module name description in Kconfig for tpm_i2c_infineon
tpm: use tabs instead of whitespaces in Kconfig
Roberto Sassu (9):
ima: pass the file descriptor to ima_add_violation()
ima: pass the filename argument up to ima_add_template_entry()
ima: define new function ima_alloc_init_template() to API
ima: new templates management mechanism
ima: define template fields library and new helpers
ima: define new template ima-ng and template fields d-ng and n-ng
ima: switch to new template management mechanism
ima: defer determining the appraisal hash algorithm for 'ima' template
ima: define kernel parameter 'ima_template=' to change configured default
Stephen Smalley (1):
SELinux: Enable setting security contexts on rootfs inodes.
Waiman Long (2):
SELinux: Reduce overhead of mls_level_isvalid() function call
SELinux: Increase ebitmap_node size for 64-bit configuration
Wei Yongjun (1):
KEYS: fix error return code in big_key_instantiate()
Documentation/assoc_array.txt | 574 +++++++
.../devicetree/bindings/i2c/trivial-devices.txt | 3 +
Documentation/kernel-parameters.txt | 11 +-
Documentation/security/00-INDEX | 2 +
Documentation/security/IMA-templates.txt | 87 +
Documentation/security/keys.txt | 20 +-
MAINTAINERS | 4 +-
crypto/Kconfig | 3 +
crypto/Makefile | 1 +
crypto/asymmetric_keys/Kconfig | 3 +-
crypto/asymmetric_keys/asymmetric_type.c | 1 +
crypto/asymmetric_keys/public_key.c | 66 +-
crypto/asymmetric_keys/public_key.h | 6 +
crypto/asymmetric_keys/rsa.c | 14 +-
crypto/asymmetric_keys/x509_cert_parser.c | 35 +-
crypto/asymmetric_keys/x509_parser.h | 18 +-
crypto/asymmetric_keys/x509_public_key.c | 232 ++-
crypto/hash_info.c | 56 +
drivers/char/tpm/Kconfig | 37 +-
drivers/char/tpm/Makefile | 11 +-
drivers/char/tpm/{tpm.c => tpm-interface.c} | 138 +-
drivers/char/tpm/tpm.h | 3 +-
drivers/char/tpm/tpm_atmel.c | 2 +-
drivers/char/tpm/tpm_eventlog.c | 3 -
drivers/char/tpm/tpm_i2c_atmel.c | 284 ++++
drivers/char/tpm/tpm_i2c_infineon.c | 4 +-
drivers/char/tpm/tpm_i2c_nuvoton.c | 710 ++++++++
drivers/char/tpm/tpm_i2c_stm_st33.c | 12 +-
drivers/char/tpm/tpm_ibmvtpm.c | 6 +-
drivers/char/tpm/tpm_ppi.c | 4 -
drivers/char/tpm/tpm_tis.c | 2 +-
drivers/char/tpm/xen-tpmfront.c | 2 -
include/crypto/hash_info.h | 40 +
include/crypto/public_key.h | 25 +-
include/keys/big_key-type.h | 25 +
include/keys/keyring-type.h | 17 +-
include/keys/system_keyring.h | 23 +
include/linux/assoc_array.h | 92 +
include/linux/assoc_array_priv.h | 182 ++
include/linux/key-type.h | 6 +
include/linux/key.h | 52 +-
include/linux/security.h | 26 +-
include/linux/user_namespace.h | 6 +
include/uapi/linux/hash_info.h | 37 +
include/uapi/linux/keyctl.h | 1 +
init/Kconfig | 13 +
kernel/Makefile | 50 +-
kernel/modsign_certificate.S | 12 -
kernel/modsign_pubkey.c | 104 --
kernel/module-internal.h | 2 -
kernel/module_signing.c | 11 +-
kernel/system_certificates.S | 10 +
kernel/system_keyring.c | 105 ++
kernel/user.c | 4 +
kernel/user_namespace.c | 6 +
lib/Kconfig | 14 +
lib/Makefile | 1 +
lib/assoc_array.c | 1746 ++++++++++++++++++++
lib/mpi/mpiutil.c | 3 +
scripts/asn1_compiler.c | 2 +
security/Makefile | 1 -
security/apparmor/audit.c | 14 +-
security/apparmor/capability.c | 15 +-
security/apparmor/domain.c | 16 +-
security/apparmor/include/audit.h | 1 -
security/apparmor/include/capability.h | 5 +-
security/apparmor/include/ipc.h | 4 +-
security/apparmor/ipc.c | 9 +-
security/apparmor/lsm.c | 2 +-
security/capability.c | 15 +-
security/integrity/digsig.c | 37 +-
security/integrity/digsig_asymmetric.c | 11 -
security/integrity/evm/evm_main.c | 4 +-
security/integrity/evm/evm_posix_acl.c | 3 +-
security/integrity/iint.c | 2 +
security/integrity/ima/Kconfig | 72 +
security/integrity/ima/Makefile | 2 +-
security/integrity/ima/ima.h | 101 +-
security/integrity/ima/ima_api.c | 136 ++-
security/integrity/ima/ima_appraise.c | 117 ++-
security/integrity/ima/ima_crypto.c | 134 ++-
security/integrity/ima/ima_fs.c | 67 +-
security/integrity/ima/ima_init.c | 37 +-
security/integrity/ima/ima_main.c | 63 +-
security/integrity/ima/ima_policy.c | 1 -
security/integrity/ima/ima_queue.c | 10 +-
security/integrity/ima/ima_template.c | 178 ++
security/integrity/ima/ima_template_lib.c | 347 ++++
security/integrity/ima/ima_template_lib.h | 49 +
security/integrity/integrity.h | 47 +-
security/keys/Kconfig | 29 +
security/keys/Makefile | 2 +
security/keys/big_key.c | 206 +++
security/keys/compat.c | 3 +
security/keys/gc.c | 33 +-
security/keys/internal.h | 74 +-
security/keys/key.c | 102 +-
security/keys/keyctl.c | 3 +
security/keys/keyring.c | 1505 +++++++++--------
security/keys/persistent.c | 169 ++
security/keys/proc.c | 17 +-
security/keys/process_keys.c | 141 +-
security/keys/request_key.c | 60 +-
security/keys/request_key_auth.c | 31 +-
security/keys/sysctl.c | 11 +
security/keys/user_defined.c | 18 +-
security/security.c | 13 +-
security/selinux/hooks.c | 146 ++-
security/selinux/include/objsec.h | 4 +-
security/selinux/include/security.h | 13 +-
security/selinux/include/xfrm.h | 45 +-
security/selinux/netlabel.c | 6 +-
security/selinux/netnode.c | 2 +
security/selinux/selinuxfs.c | 4 +-
security/selinux/ss/ebitmap.c | 20 +-
security/selinux/ss/ebitmap.h | 10 +-
security/selinux/ss/mls.c | 22 +-
security/selinux/ss/mls_types.h | 2 +-
security/selinux/ss/policydb.c | 3 +-
security/selinux/ss/services.c | 66 +-
security/selinux/xfrm.c | 453 +++---
security/smack/smack.h | 12 +-
security/smack/smack_access.c | 10 +
security/smack/smack_lsm.c | 11 +-
security/smack/smackfs.c | 10 +-
125 files changed, 7697 insertions(+), 2028 deletions(-)
create mode 100644 Documentation/assoc_array.txt
create mode 100644 Documentation/security/IMA-templates.txt
create mode 100644 crypto/hash_info.c
rename drivers/char/tpm/{tpm.c => tpm-interface.c} (93%)
create mode 100644 drivers/char/tpm/tpm_i2c_atmel.c
create mode 100644 drivers/char/tpm/tpm_i2c_nuvoton.c
create mode 100644 include/crypto/hash_info.h
create mode 100644 include/keys/big_key-type.h
create mode 100644 include/keys/system_keyring.h
create mode 100644 include/linux/assoc_array.h
create mode 100644 include/linux/assoc_array_priv.h
create mode 100644 include/uapi/linux/hash_info.h
delete mode 100644 kernel/modsign_certificate.S
delete mode 100644 kernel/modsign_pubkey.c
create mode 100644 kernel/system_certificates.S
create mode 100644 kernel/system_keyring.c
create mode 100644 lib/assoc_array.c
create mode 100644 security/integrity/ima/ima_template.c
create mode 100644 security/integrity/ima/ima_template_lib.c
create mode 100644 security/integrity/ima/ima_template_lib.h
create mode 100644 security/keys/big_key.c
create mode 100644 security/keys/persistent.c
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: [GIT] Security subsystem updates for 3.13 2013-11-07 0:51 [GIT] Security subsystem updates for 3.13 James Morris @ 2013-11-18 15:31 ` Josh Boyer 2013-11-18 23:30 ` James Morris 0 siblings, 1 reply; 14+ messages in thread From: Josh Boyer @ 2013-11-18 15:31 UTC (permalink / raw) To: James Morris Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, linux-security-module On Wed, Nov 6, 2013 at 7:51 PM, James Morris <jmorris@namei.org> wrote: > In this patchset, we finally get an SELinux update, with Paul Moore taking > over as maintainer of that code. > > Also a significant update for the Keys subsystem, as well as maintenance > updates to Smack, IMA, TPM, and Apparmor. > > Please pull. > > The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus Unless I'm missing something, I don't think this has landed in Linus' tree yet. Linus, did this pull request get NAKed or fall through the cracks? josh > > Anand Avati (1): > selinux: consider filesystem subtype in policies > > Antonio Alecrim Jr (1): > X.509: remove possible code fragility: enumeration values not handled > > Casey Schaufler (2): > Smack: Implement lock security mode > Smack: Ptrace access check mode > > Chen Gang (1): > kernel/system_certificate.S: use real contents instead of macro GLOBAL() > > Chris PeBenito (1): > Add SELinux policy capability for always checking packet and peer classes. > > David Howells (29): > KEYS: Skip key state checks when checking for possession > KEYS: Use bool in make_key_ref() and is_key_possessed() > KEYS: key_is_dead() should take a const key pointer argument > KEYS: Consolidate the concept of an 'index key' for key access > KEYS: Introduce a search context structure > KEYS: Search for auth-key by name rather than target key ID > KEYS: Define a __key_get() wrapper to use rather than atomic_inc() > KEYS: Drop the permissions argument from __keyring_search_one() > Add a generic associative array implementation. > KEYS: Expand the capacity of a keyring > KEYS: Implement a big key type that can save to tmpfs > KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches > KEYS: Rename public key parameter name arrays > KEYS: Move the algorithm pointer array from x509 to public_key.c > KEYS: Store public key algo ID in public_key struct > KEYS: Split public_key_verify_signature() and make available > KEYS: Store public key algo ID in public_key_signature struct > X.509: struct x509_certificate needs struct tm declaring > X.509: Embed public_key_signature struct and create filler function > X.509: Check the algorithm IDs obtained from parsing an X.509 certificate > X.509: Handle certificates that lack an authorityKeyIdentifier field > X.509: Remove certificate date checks > KEYS: Load *.x509 files into kernel keyring > KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate > KEYS: Separate the kernel signature checking keyring from module signing > KEYS: Add a 'trusted' flag and a 'trusted only' flag > KEYS: Set the asymmetric-key type default search method > KEYS: Fix a race between negating a key and reading the error set > KEYS: Fix keyring quota misaccounting on key replacement and unlink > > Dmitry Kasatkin (11): > ima: fix script messages > crypto: provide single place for hash algo information > keys: change asymmetric keys to use common hash definitions > ima: provide support for arbitrary hash algorithms > ima: read and use signature hash algorithm > ima: pass full xattr with the signature > ima: use dynamically allocated hash storage > ima: provide dedicated hash algo allocation function > ima: support arbitrary hash algorithms in ima_calc_buffer_hash > ima: ima_calc_boot_agregate must use SHA1 > ima: provide hash algo info in the xattr > > Duan Jiong (1): > selinux: Use kmemdup instead of kmalloc + memcpy > > Eric Paris (13): > SELinux: fix selinuxfs policy file on big endian systems > SELinux: remove crazy contortions around proc > SELinux: make it harder to get the number of mnt opts wrong > SELinux: use define for number of bits in the mnt flags mask > SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT > SELinux: do all flags twiddling in one place > SELinux: renumber the superblock options > SELinux: change sbsec->behavior to short > SELinux: do not handle seclabel as a special flag > SELinux: pass a superblock to security_fs_use > SELinux: use a helper function to determine seclabel > Revert "SELinux: do not handle seclabel as a special flag" > security: remove erroneous comment about capabilities.o link ordering > > James Morris (3): > Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next > Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next > Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next > > Jason Gunthorpe (11): > tpm: ibmvtpm: Use %zd formatting for size_t format arguments > tpm atmel: Call request_region with the correct base > tpm: Store devname in the tpm_chip > tpm: Use container_of to locate the tpm_chip in tpm_open > tpm: Remove redundant dev_set_drvdata > tpm: st33: Remove chip->data_buffer access from this driver > tpm: Remove tpm_show_caps_1_2 > tpm: Rename tpm.c to tpm-interface.c > tpm: Merge the tpm-bios module with tpm.o > tpm: Add support for the Nuvoton NPCT501 I2C TPM > tpm: Add support for Atmel I2C TPMs > > John Johansen (3): > apparmor: fix capability to not use the current task, during reporting > apparmor: remove tsk field from the apparmor_audit_struct > apparmor: remove parent task info from audit logging > > Josh Boyer (1): > KEYS: Make BIG_KEYS boolean > > Konstantin Khlebnikov (2): > MPILIB: add module description and license > X.509: add module description and license > > Mimi Zohar (10): > KEYS: Make the system 'trusted' keyring viewable by userspace > KEYS: verify a certificate is signed by a 'trusted' key > KEYS: initialize root uid and session keyrings early > Revert "ima: policy for RAMFS" > ima: differentiate between template hash and file data hash sizes > ima: add audit log support for larger hashes > ima: add Kconfig default measurement list template > ima: enable support for larger default filedata hash algorithms > ima: extend the measurement list to include the file signature > ima: define '_ima' as a builtin 'trusted' keyring > > Oleg Nesterov (1): > apparmor: remove the "task" arg from may_change_ptraced_domain() > > Paul Moore (13): > lsm: split the xfrm_state_alloc_security() hook implementation > selinux: cleanup and consolidate the XFRM alloc/clone/delete/free code > selinux: cleanup selinux_xfrm_policy_lookup() and selinux_xfrm_state_pol_flow_match() > selinux: cleanup selinux_xfrm_sock_rcv_skb() and selinux_xfrm_postroute_last() > selinux: cleanup some comment and whitespace issues in the XFRM code > selinux: cleanup selinux_xfrm_decode_session() > selinux: cleanup the XFRM header > selinux: remove the BUG_ON() from selinux_skb_xfrm_sid() > selinux: fix problems in netnode when BUG() is compiled out > Merge git://git.infradead.org/users/eparis/selinux > selinux: add Paul Moore as a SELinux maintainer > selinux: add Paul Moore as a SELinux maintainer > selinux: correct locking in selinux_netlbl_socket_connect) > > Peter Huewe (4): > tpm: MAINTAINERS: Add myself as tpm maintainer > tpm: cleanup checkpatch warnings > tpm: Fix module name description in Kconfig for tpm_i2c_infineon > tpm: use tabs instead of whitespaces in Kconfig > > Roberto Sassu (9): > ima: pass the file descriptor to ima_add_violation() > ima: pass the filename argument up to ima_add_template_entry() > ima: define new function ima_alloc_init_template() to API > ima: new templates management mechanism > ima: define template fields library and new helpers > ima: define new template ima-ng and template fields d-ng and n-ng > ima: switch to new template management mechanism > ima: defer determining the appraisal hash algorithm for 'ima' template > ima: define kernel parameter 'ima_template=' to change configured default > > Stephen Smalley (1): > SELinux: Enable setting security contexts on rootfs inodes. > > Waiman Long (2): > SELinux: Reduce overhead of mls_level_isvalid() function call > SELinux: Increase ebitmap_node size for 64-bit configuration > > Wei Yongjun (1): > KEYS: fix error return code in big_key_instantiate() > > Documentation/assoc_array.txt | 574 +++++++ > .../devicetree/bindings/i2c/trivial-devices.txt | 3 + > Documentation/kernel-parameters.txt | 11 +- > Documentation/security/00-INDEX | 2 + > Documentation/security/IMA-templates.txt | 87 + > Documentation/security/keys.txt | 20 +- > MAINTAINERS | 4 +- > crypto/Kconfig | 3 + > crypto/Makefile | 1 + > crypto/asymmetric_keys/Kconfig | 3 +- > crypto/asymmetric_keys/asymmetric_type.c | 1 + > crypto/asymmetric_keys/public_key.c | 66 +- > crypto/asymmetric_keys/public_key.h | 6 + > crypto/asymmetric_keys/rsa.c | 14 +- > crypto/asymmetric_keys/x509_cert_parser.c | 35 +- > crypto/asymmetric_keys/x509_parser.h | 18 +- > crypto/asymmetric_keys/x509_public_key.c | 232 ++- > crypto/hash_info.c | 56 + > drivers/char/tpm/Kconfig | 37 +- > drivers/char/tpm/Makefile | 11 +- > drivers/char/tpm/{tpm.c => tpm-interface.c} | 138 +- > drivers/char/tpm/tpm.h | 3 +- > drivers/char/tpm/tpm_atmel.c | 2 +- > drivers/char/tpm/tpm_eventlog.c | 3 - > drivers/char/tpm/tpm_i2c_atmel.c | 284 ++++ > drivers/char/tpm/tpm_i2c_infineon.c | 4 +- > drivers/char/tpm/tpm_i2c_nuvoton.c | 710 ++++++++ > drivers/char/tpm/tpm_i2c_stm_st33.c | 12 +- > drivers/char/tpm/tpm_ibmvtpm.c | 6 +- > drivers/char/tpm/tpm_ppi.c | 4 - > drivers/char/tpm/tpm_tis.c | 2 +- > drivers/char/tpm/xen-tpmfront.c | 2 - > include/crypto/hash_info.h | 40 + > include/crypto/public_key.h | 25 +- > include/keys/big_key-type.h | 25 + > include/keys/keyring-type.h | 17 +- > include/keys/system_keyring.h | 23 + > include/linux/assoc_array.h | 92 + > include/linux/assoc_array_priv.h | 182 ++ > include/linux/key-type.h | 6 + > include/linux/key.h | 52 +- > include/linux/security.h | 26 +- > include/linux/user_namespace.h | 6 + > include/uapi/linux/hash_info.h | 37 + > include/uapi/linux/keyctl.h | 1 + > init/Kconfig | 13 + > kernel/Makefile | 50 +- > kernel/modsign_certificate.S | 12 - > kernel/modsign_pubkey.c | 104 -- > kernel/module-internal.h | 2 - > kernel/module_signing.c | 11 +- > kernel/system_certificates.S | 10 + > kernel/system_keyring.c | 105 ++ > kernel/user.c | 4 + > kernel/user_namespace.c | 6 + > lib/Kconfig | 14 + > lib/Makefile | 1 + > lib/assoc_array.c | 1746 ++++++++++++++++++++ > lib/mpi/mpiutil.c | 3 + > scripts/asn1_compiler.c | 2 + > security/Makefile | 1 - > security/apparmor/audit.c | 14 +- > security/apparmor/capability.c | 15 +- > security/apparmor/domain.c | 16 +- > security/apparmor/include/audit.h | 1 - > security/apparmor/include/capability.h | 5 +- > security/apparmor/include/ipc.h | 4 +- > security/apparmor/ipc.c | 9 +- > security/apparmor/lsm.c | 2 +- > security/capability.c | 15 +- > security/integrity/digsig.c | 37 +- > security/integrity/digsig_asymmetric.c | 11 - > security/integrity/evm/evm_main.c | 4 +- > security/integrity/evm/evm_posix_acl.c | 3 +- > security/integrity/iint.c | 2 + > security/integrity/ima/Kconfig | 72 + > security/integrity/ima/Makefile | 2 +- > security/integrity/ima/ima.h | 101 +- > security/integrity/ima/ima_api.c | 136 ++- > security/integrity/ima/ima_appraise.c | 117 ++- > security/integrity/ima/ima_crypto.c | 134 ++- > security/integrity/ima/ima_fs.c | 67 +- > security/integrity/ima/ima_init.c | 37 +- > security/integrity/ima/ima_main.c | 63 +- > security/integrity/ima/ima_policy.c | 1 - > security/integrity/ima/ima_queue.c | 10 +- > security/integrity/ima/ima_template.c | 178 ++ > security/integrity/ima/ima_template_lib.c | 347 ++++ > security/integrity/ima/ima_template_lib.h | 49 + > security/integrity/integrity.h | 47 +- > security/keys/Kconfig | 29 + > security/keys/Makefile | 2 + > security/keys/big_key.c | 206 +++ > security/keys/compat.c | 3 + > security/keys/gc.c | 33 +- > security/keys/internal.h | 74 +- > security/keys/key.c | 102 +- > security/keys/keyctl.c | 3 + > security/keys/keyring.c | 1505 +++++++++-------- > security/keys/persistent.c | 169 ++ > security/keys/proc.c | 17 +- > security/keys/process_keys.c | 141 +- > security/keys/request_key.c | 60 +- > security/keys/request_key_auth.c | 31 +- > security/keys/sysctl.c | 11 + > security/keys/user_defined.c | 18 +- > security/security.c | 13 +- > security/selinux/hooks.c | 146 ++- > security/selinux/include/objsec.h | 4 +- > security/selinux/include/security.h | 13 +- > security/selinux/include/xfrm.h | 45 +- > security/selinux/netlabel.c | 6 +- > security/selinux/netnode.c | 2 + > security/selinux/selinuxfs.c | 4 +- > security/selinux/ss/ebitmap.c | 20 +- > security/selinux/ss/ebitmap.h | 10 +- > security/selinux/ss/mls.c | 22 +- > security/selinux/ss/mls_types.h | 2 +- > security/selinux/ss/policydb.c | 3 +- > security/selinux/ss/services.c | 66 +- > security/selinux/xfrm.c | 453 +++--- > security/smack/smack.h | 12 +- > security/smack/smack_access.c | 10 + > security/smack/smack_lsm.c | 11 +- > security/smack/smackfs.c | 10 +- > 125 files changed, 7697 insertions(+), 2028 deletions(-) > create mode 100644 Documentation/assoc_array.txt > create mode 100644 Documentation/security/IMA-templates.txt > create mode 100644 crypto/hash_info.c > rename drivers/char/tpm/{tpm.c => tpm-interface.c} (93%) > create mode 100644 drivers/char/tpm/tpm_i2c_atmel.c > create mode 100644 drivers/char/tpm/tpm_i2c_nuvoton.c > create mode 100644 include/crypto/hash_info.h > create mode 100644 include/keys/big_key-type.h > create mode 100644 include/keys/system_keyring.h > create mode 100644 include/linux/assoc_array.h > create mode 100644 include/linux/assoc_array_priv.h > create mode 100644 include/uapi/linux/hash_info.h > delete mode 100644 kernel/modsign_certificate.S > delete mode 100644 kernel/modsign_pubkey.c > create mode 100644 kernel/system_certificates.S > create mode 100644 kernel/system_keyring.c > create mode 100644 lib/assoc_array.c > create mode 100644 security/integrity/ima/ima_template.c > create mode 100644 security/integrity/ima/ima_template_lib.c > create mode 100644 security/integrity/ima/ima_template_lib.h > create mode 100644 security/keys/big_key.c > create mode 100644 security/keys/persistent.c > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-18 15:31 ` Josh Boyer @ 2013-11-18 23:30 ` James Morris 2013-11-18 23:54 ` Linus Torvalds 0 siblings, 1 reply; 14+ messages in thread From: James Morris @ 2013-11-18 23:30 UTC (permalink / raw) To: Josh Boyer Cc: Linus Torvalds, Linux-Kernel@Vger. Kernel. Org, linux-security-module On Mon, 18 Nov 2013, Josh Boyer wrote: > On Wed, Nov 6, 2013 at 7:51 PM, James Morris <jmorris@namei.org> wrote: > > In this patchset, we finally get an SELinux update, with Paul Moore taking > > over as maintainer of that code. > > > > Also a significant update for the Keys subsystem, as well as maintenance > > updates to Smack, IMA, TPM, and Apparmor. > > > > Please pull. > > > > The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: > > > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus > > Unless I'm missing something, I don't think this has landed in Linus' > tree yet. Linus, did this pull request get NAKed or fall through the > cracks? I think Linus is on vacation and merging only sporadically at the moment. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-18 23:30 ` James Morris @ 2013-11-18 23:54 ` Linus Torvalds 2013-11-19 5:38 ` James Morris 2013-11-19 12:20 ` James Morris 0 siblings, 2 replies; 14+ messages in thread From: Linus Torvalds @ 2013-11-18 23:54 UTC (permalink / raw) To: James Morris Cc: Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module On Mon, Nov 18, 2013 at 3:30 PM, James Morris <jmorris@namei.org> wrote: > On Mon, 18 Nov 2013, Josh Boyer wrote: >> >> Unless I'm missing something, I don't think this has landed in Linus' >> tree yet. Linus, did this pull request get NAKed or fall through the >> cracks? > > I think Linus is on vacation and merging only sporadically at the moment. No,while it is true that I've been traveling, I've also been actively merging, and no, that pull request isn't lost. I don't really like the look of it though (particularly all the magic new keys changes), so I've been delaying it and merging other regular stuff that I don't have any issues with. I'm leaving that pull for later in order to go over it more carefully when I'm not doing fifteen other pulls the same day.. If somebody wants to explain about the rationale new keys code, that might help. Linus ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-18 23:54 ` Linus Torvalds @ 2013-11-19 5:38 ` James Morris 2013-11-19 14:46 ` David Howells 2013-11-19 12:20 ` James Morris 1 sibling, 1 reply; 14+ messages in thread From: James Morris @ 2013-11-19 5:38 UTC (permalink / raw) To: Linus Torvalds Cc: Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module, David Howells On Mon, 18 Nov 2013, Linus Torvalds wrote: > On Mon, Nov 18, 2013 at 3:30 PM, James Morris <jmorris@namei.org> wrote: > > On Mon, 18 Nov 2013, Josh Boyer wrote: > >> > >> Unless I'm missing something, I don't think this has landed in Linus' > >> tree yet. Linus, did this pull request get NAKed or fall through the > >> cracks? > > > > I think Linus is on vacation and merging only sporadically at the moment. > > No,while it is true that I've been traveling, I've also been actively > merging, and no, that pull request isn't lost. > > I don't really like the look of it though (particularly all the magic > new keys changes), so I've been delaying it and merging other regular > stuff that I don't have any issues with. I'm leaving that pull for > later in order to go over it more carefully when I'm not doing fifteen > other pulls the same day.. > > If somebody wants to explain about the rationale new keys code, that might help. Thanks -- I've cc'd David for comment. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-19 5:38 ` James Morris @ 2013-11-19 14:46 ` David Howells 0 siblings, 0 replies; 14+ messages in thread From: David Howells @ 2013-11-19 14:46 UTC (permalink / raw) To: James Morris, Linus Torvalds Cc: dhowells, Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module James Morris <jmorris@namei.org> wrote: > On Mon, 18 Nov 2013, Linus Torvalds wrote: > ... > > If somebody wants to explain about the rationale new keys code, that might > > help. Okay. There are a number of separate bits. I'll go over the big bits and the odd important other bit, most of the smaller bits are just fixes and cleanups. If you want the small bits accounting for, I can do that too. (1) Keyring capacity expansion. KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID Add a generic associative array implementation. KEYS: Expand the capacity of a keyring Several of the patches are providing an expansion of the capacity of a keyring. Currently, the maximum size of a keyring payload is one page. Subtract a small header and then divide up into pointers, that only gives you ~500 pointers on an x86_64 box. However, since the NFS idmapper uses a keyring to store ID mapping data, that has proven to be insufficient to the cause. Whatever data structure I use to handle the keyring payload, it can only store pointers to keys, not the keys themselves because several keyrings may point to a single key. This precludes inserting, say, and rb_node struct into the key struct for this purpose. I could make an rbtree of records such that each record has an rb_node and a key pointer, but that would use four words of space per key stored in the keyring. It would, however, be able to use much existing code. I selected instead a non-rebalancing radix-tree type approach as that could have a better space-used/key-pointer ratio. I could have used the radix tree implementation that we already have and insert keys into it by their serial numbers, but that means any sort of search must iterate over the whole radix tree. Further, its nodes are a bit on the capacious side for what I want - especially given that key serial numbers are randomly allocated, thus leaving a lot of empty space in the tree. So what I have is an associative array that internally is a radix-tree with 16 pointers per node where the index key is constructed from the key type pointer and the key description. This means that an exact lookup by type+description is very fast as this tells us how to navigate directly to the target key. I made the data structure general in lib/assoc_array.c as far as it is concerned, its index key is just a sequence of bits that leads to a pointer. It's possible that someone else will be able to make use of it also. FS-Cache might, for example. (2) Mark keys as 'trusted' and keyrings as 'trusted only'. KEYS: verify a certificate is signed by a 'trusted' key KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Separate the kernel signature checking keyring from module signing These patches allow keys carrying asymmetric public keys to be marked as being 'trusted' and allow keyrings to be marked as only permitting the addition or linkage of trusted keys. Keys loaded from hardware during kernel boot or compiled into the kernel during build are marked as being trusted automatically. New keys can be loaded at runtime with add_key(). They are checked against the system keyring contents and if their signatures can be validated with keys that are already marked trusted, then they are marked trusted also and can thus be added into the master keyring. Patches from Mimi Zohar make this usable with the IMA keyrings also. (3) Remove the date checks on the key used to validate a module signature. X.509: Remove certificate date checks It's not reasonable to reject a signature just because the key that it was generated with is no longer valid datewise - especially if the kernel hasn't yet managed to set the system clock when the first module is loaded - so just remove those checks. (4) Make it simpler to deal with additional X.509 being loaded into the kernel. KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate The builder of the kernel now just places files with the extension ".x509" into the kernel source or build trees and they're concatenated by the kernel build and stuffed into the appropriate section. (5) Add support for userspace kerberos to use keyrings. KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Implement a big key type that can save to tmpfs Fedora went to, by default, storing kerberos tickets and tokens in tmpfs. We looked at storing it in keyrings instead as that confers certain advantages such as tickets being automatically deleted after a certain amount of time and the ability for the kernel to get at these tokens more easily. To make this work, two things were needed: (a) A way for the tickets to persist beyond the lifetime of all a user's sessions so that cron-driven processes can still use them. The problem is that a user's session keyrings are deleted when the session that spawned them logs out and the user's user keyring is deleted when the UID is deleted (typically when the last log out happens), so neither of these places is suitable. I've added a system keyring into which a 'persistent' keyring is created for each UID on request. Each time a user requests their persistent keyring, the expiry time on it is set anew. If the user doesn't ask for it for, say, three days, the keyring is automatically expired and garbage collected using the existing gc. All the kerberos tokens it held are then also gc'd. (b) A key type that can hold really big tickets (up to 1MB in size). The problem is that Active Directory can return huge tickets with lots of auxiliary data attached. We don't, however, want to eat up huge tracts of unswappable kernel space for this, so if the ticket is greater than a certain size, we create a swappable shmem file and dump the contents in there and just live with the fact we then have an inode and a dentry overhead. If the ticket is smaller than that, we slap it in a kmalloc()'d buffer. David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-18 23:54 ` Linus Torvalds 2013-11-19 5:38 ` James Morris @ 2013-11-19 12:20 ` James Morris 2013-11-22 4:22 ` Linus Torvalds 1 sibling, 1 reply; 14+ messages in thread From: James Morris @ 2013-11-19 12:20 UTC (permalink / raw) To: Linus Torvalds Cc: Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module, David Howells Also, here's an updated branch to pull from with four new fixes from David. --- The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus2 Anand Avati (1): selinux: consider filesystem subtype in policies Antonio Alecrim Jr (1): X.509: remove possible code fragility: enumeration values not handled Casey Schaufler (2): Smack: Implement lock security mode Smack: Ptrace access check mode Chen Gang (1): kernel/system_certificate.S: use real contents instead of macro GLOBAL() Chris PeBenito (1): Add SELinux policy capability for always checking packet and peer classes. David Howells (33): KEYS: Skip key state checks when checking for possession KEYS: Use bool in make_key_ref() and is_key_possessed() KEYS: key_is_dead() should take a const key pointer argument KEYS: Consolidate the concept of an 'index key' for key access KEYS: Introduce a search context structure KEYS: Search for auth-key by name rather than target key ID KEYS: Define a __key_get() wrapper to use rather than atomic_inc() KEYS: Drop the permissions argument from __keyring_search_one() Add a generic associative array implementation. KEYS: Expand the capacity of a keyring KEYS: Implement a big key type that can save to tmpfs KEYS: Add per-user_namespace registers for persistent per-UID kerberos caches KEYS: Rename public key parameter name arrays KEYS: Move the algorithm pointer array from x509 to public_key.c KEYS: Store public key algo ID in public_key struct KEYS: Split public_key_verify_signature() and make available KEYS: Store public key algo ID in public_key_signature struct X.509: struct x509_certificate needs struct tm declaring X.509: Embed public_key_signature struct and create filler function X.509: Check the algorithm IDs obtained from parsing an X.509 certificate X.509: Handle certificates that lack an authorityKeyIdentifier field X.509: Remove certificate date checks KEYS: Load *.x509 files into kernel keyring KEYS: Have make canonicalise the paths of the X.509 certs better to deduplicate KEYS: Separate the kernel signature checking keyring from module signing KEYS: Add a 'trusted' flag and a 'trusted only' flag KEYS: Set the asymmetric-key type default search method KEYS: Fix a race between negating a key and reading the error set KEYS: Fix keyring quota misaccounting on key replacement and unlink KEYS: The RSA public key algorithm needs to select MPILIB KEYS: Fix UID check in keyctl_get_persistent() KEYS: Fix error handling in big_key instantiation KEYS: Fix keyring content gc scanner Dmitry Kasatkin (11): ima: fix script messages crypto: provide single place for hash algo information keys: change asymmetric keys to use common hash definitions ima: provide support for arbitrary hash algorithms ima: read and use signature hash algorithm ima: pass full xattr with the signature ima: use dynamically allocated hash storage ima: provide dedicated hash algo allocation function ima: support arbitrary hash algorithms in ima_calc_buffer_hash ima: ima_calc_boot_agregate must use SHA1 ima: provide hash algo info in the xattr Duan Jiong (1): selinux: Use kmemdup instead of kmalloc + memcpy Eric Paris (13): SELinux: fix selinuxfs policy file on big endian systems SELinux: remove crazy contortions around proc SELinux: make it harder to get the number of mnt opts wrong SELinux: use define for number of bits in the mnt flags mask SELinux: rename SE_SBLABELSUPP to SBLABEL_MNT SELinux: do all flags twiddling in one place SELinux: renumber the superblock options SELinux: change sbsec->behavior to short SELinux: do not handle seclabel as a special flag SELinux: pass a superblock to security_fs_use SELinux: use a helper function to determine seclabel Revert "SELinux: do not handle seclabel as a special flag" security: remove erroneous comment about capabilities.o link ordering James Morris (3): Merge branch 'master' of git://git.infradead.org/users/pcmoore/selinux into ra-next Merge branch 'smack-for-3.13' of git://git.gitorious.org/smack-next/kernel into ra-next Merge branch 'keys-devel' of git://git.kernel.org/.../dhowells/linux-fs into ra-next Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open tpm: Remove redundant dev_set_drvdata tpm: st33: Remove chip->data_buffer access from this driver tpm: Remove tpm_show_caps_1_2 tpm: Rename tpm.c to tpm-interface.c tpm: Merge the tpm-bios module with tpm.o tpm: Add support for the Nuvoton NPCT501 I2C TPM tpm: Add support for Atmel I2C TPMs John Johansen (3): apparmor: fix capability to not use the current task, during reporting apparmor: remove tsk field from the apparmor_audit_struct apparmor: remove parent task info from audit logging Josh Boyer (1): KEYS: Make BIG_KEYS boolean Konstantin Khlebnikov (2): MPILIB: add module description and license X.509: add module description and license Mimi Zohar (10): KEYS: Make the system 'trusted' keyring viewable by userspace KEYS: verify a certificate is signed by a 'trusted' key KEYS: initialize root uid and session keyrings early Revert "ima: policy for RAMFS" ima: differentiate between template hash and file data hash sizes ima: add audit log support for larger hashes ima: add Kconfig default measurement list template ima: enable support for larger default filedata hash algorithms ima: extend the measurement list to include the file signature ima: define '_ima' as a builtin 'trusted' keyring Oleg Nesterov (1): apparmor: remove the "task" arg from may_change_ptraced_domain() Paul Moore (13): lsm: split the xfrm_state_alloc_security() hook implementation selinux: cleanup and consolidate the XFRM alloc/clone/delete/free code selinux: cleanup selinux_xfrm_policy_lookup() and selinux_xfrm_state_pol_flow_match() selinux: cleanup selinux_xfrm_sock_rcv_skb() and selinux_xfrm_postroute_last() selinux: cleanup some comment and whitespace issues in the XFRM code selinux: cleanup selinux_xfrm_decode_session() selinux: cleanup the XFRM header selinux: remove the BUG_ON() from selinux_skb_xfrm_sid() selinux: fix problems in netnode when BUG() is compiled out Merge git://git.infradead.org/users/eparis/selinux selinux: add Paul Moore as a SELinux maintainer selinux: add Paul Moore as a SELinux maintainer selinux: correct locking in selinux_netlbl_socket_connect) Peter Huewe (4): tpm: MAINTAINERS: Add myself as tpm maintainer tpm: cleanup checkpatch warnings tpm: Fix module name description in Kconfig for tpm_i2c_infineon tpm: use tabs instead of whitespaces in Kconfig Roberto Sassu (9): ima: pass the file descriptor to ima_add_violation() ima: pass the filename argument up to ima_add_template_entry() ima: define new function ima_alloc_init_template() to API ima: new templates management mechanism ima: define template fields library and new helpers ima: define new template ima-ng and template fields d-ng and n-ng ima: switch to new template management mechanism ima: defer determining the appraisal hash algorithm for 'ima' template ima: define kernel parameter 'ima_template=' to change configured default Stephen Smalley (1): SELinux: Enable setting security contexts on rootfs inodes. Waiman Long (2): SELinux: Reduce overhead of mls_level_isvalid() function call SELinux: Increase ebitmap_node size for 64-bit configuration Wei Yongjun (1): KEYS: fix error return code in big_key_instantiate() Documentation/assoc_array.txt | 574 +++++++ .../devicetree/bindings/i2c/trivial-devices.txt | 3 + Documentation/kernel-parameters.txt | 11 +- Documentation/security/00-INDEX | 2 + Documentation/security/IMA-templates.txt | 87 + Documentation/security/keys.txt | 20 +- MAINTAINERS | 4 +- crypto/Kconfig | 3 + crypto/Makefile | 1 + crypto/asymmetric_keys/Kconfig | 4 +- crypto/asymmetric_keys/asymmetric_type.c | 1 + crypto/asymmetric_keys/public_key.c | 66 +- crypto/asymmetric_keys/public_key.h | 6 + crypto/asymmetric_keys/rsa.c | 14 +- crypto/asymmetric_keys/x509_cert_parser.c | 35 +- crypto/asymmetric_keys/x509_parser.h | 18 +- crypto/asymmetric_keys/x509_public_key.c | 232 ++- crypto/hash_info.c | 56 + drivers/char/tpm/Kconfig | 37 +- drivers/char/tpm/Makefile | 11 +- drivers/char/tpm/{tpm.c => tpm-interface.c} | 138 +- drivers/char/tpm/tpm.h | 3 +- drivers/char/tpm/tpm_atmel.c | 2 +- drivers/char/tpm/tpm_eventlog.c | 3 - drivers/char/tpm/tpm_i2c_atmel.c | 284 ++++ drivers/char/tpm/tpm_i2c_infineon.c | 4 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 710 ++++++++ drivers/char/tpm/tpm_i2c_stm_st33.c | 12 +- drivers/char/tpm/tpm_ibmvtpm.c | 6 +- drivers/char/tpm/tpm_ppi.c | 4 - drivers/char/tpm/tpm_tis.c | 2 +- drivers/char/tpm/xen-tpmfront.c | 2 - include/crypto/hash_info.h | 40 + include/crypto/public_key.h | 25 +- include/keys/big_key-type.h | 25 + include/keys/keyring-type.h | 17 +- include/keys/system_keyring.h | 23 + include/linux/assoc_array.h | 92 + include/linux/assoc_array_priv.h | 182 ++ include/linux/key-type.h | 6 + include/linux/key.h | 52 +- include/linux/security.h | 26 +- include/linux/user_namespace.h | 6 + include/uapi/linux/hash_info.h | 37 + include/uapi/linux/keyctl.h | 1 + init/Kconfig | 13 + kernel/Makefile | 50 +- kernel/modsign_certificate.S | 12 - kernel/modsign_pubkey.c | 104 -- kernel/module-internal.h | 2 - kernel/module_signing.c | 11 +- kernel/system_certificates.S | 10 + kernel/system_keyring.c | 105 ++ kernel/user.c | 4 + kernel/user_namespace.c | 6 + lib/Kconfig | 14 + lib/Makefile | 1 + lib/assoc_array.c | 1746 ++++++++++++++++++++ lib/mpi/mpiutil.c | 3 + scripts/asn1_compiler.c | 2 + security/Makefile | 1 - security/apparmor/audit.c | 14 +- security/apparmor/capability.c | 15 +- security/apparmor/domain.c | 16 +- security/apparmor/include/audit.h | 1 - security/apparmor/include/capability.h | 5 +- security/apparmor/include/ipc.h | 4 +- security/apparmor/ipc.c | 9 +- security/apparmor/lsm.c | 2 +- security/capability.c | 15 +- security/integrity/digsig.c | 37 +- security/integrity/digsig_asymmetric.c | 11 - security/integrity/evm/evm_main.c | 4 +- security/integrity/evm/evm_posix_acl.c | 3 +- security/integrity/iint.c | 2 + security/integrity/ima/Kconfig | 72 + security/integrity/ima/Makefile | 2 +- security/integrity/ima/ima.h | 101 +- security/integrity/ima/ima_api.c | 136 ++- security/integrity/ima/ima_appraise.c | 117 ++- security/integrity/ima/ima_crypto.c | 134 ++- security/integrity/ima/ima_fs.c | 67 +- security/integrity/ima/ima_init.c | 37 +- security/integrity/ima/ima_main.c | 63 +- security/integrity/ima/ima_policy.c | 1 - security/integrity/ima/ima_queue.c | 10 +- security/integrity/ima/ima_template.c | 178 ++ security/integrity/ima/ima_template_lib.c | 347 ++++ security/integrity/ima/ima_template_lib.h | 49 + security/integrity/integrity.h | 47 +- security/keys/Kconfig | 29 + security/keys/Makefile | 2 + security/keys/big_key.c | 207 +++ security/keys/compat.c | 3 + security/keys/gc.c | 47 +- security/keys/internal.h | 74 +- security/keys/key.c | 102 +- security/keys/keyctl.c | 3 + security/keys/keyring.c | 1536 +++++++++-------- security/keys/persistent.c | 167 ++ security/keys/proc.c | 17 +- security/keys/process_keys.c | 141 +- security/keys/request_key.c | 60 +- security/keys/request_key_auth.c | 31 +- security/keys/sysctl.c | 11 + security/keys/user_defined.c | 18 +- security/security.c | 13 +- security/selinux/hooks.c | 146 ++- security/selinux/include/objsec.h | 4 +- security/selinux/include/security.h | 13 +- security/selinux/include/xfrm.h | 45 +- security/selinux/netlabel.c | 6 +- security/selinux/netnode.c | 2 + security/selinux/selinuxfs.c | 4 +- security/selinux/ss/ebitmap.c | 20 +- security/selinux/ss/ebitmap.h | 10 +- security/selinux/ss/mls.c | 22 +- security/selinux/ss/mls_types.h | 2 +- security/selinux/ss/policydb.c | 3 +- security/selinux/ss/services.c | 66 +- security/selinux/xfrm.c | 453 +++--- security/smack/smack.h | 12 +- security/smack/smack_access.c | 10 + security/smack/smack_lsm.c | 11 +- security/smack/smackfs.c | 10 +- 125 files changed, 7712 insertions(+), 2058 deletions(-) create mode 100644 Documentation/assoc_array.txt create mode 100644 Documentation/security/IMA-templates.txt create mode 100644 crypto/hash_info.c rename drivers/char/tpm/{tpm.c => tpm-interface.c} (93%) create mode 100644 drivers/char/tpm/tpm_i2c_atmel.c create mode 100644 drivers/char/tpm/tpm_i2c_nuvoton.c create mode 100644 include/crypto/hash_info.h create mode 100644 include/keys/big_key-type.h create mode 100644 include/keys/system_keyring.h create mode 100644 include/linux/assoc_array.h create mode 100644 include/linux/assoc_array_priv.h create mode 100644 include/uapi/linux/hash_info.h delete mode 100644 kernel/modsign_certificate.S delete mode 100644 kernel/modsign_pubkey.c create mode 100644 kernel/system_certificates.S create mode 100644 kernel/system_keyring.c create mode 100644 lib/assoc_array.c create mode 100644 security/integrity/ima/ima_template.c create mode 100644 security/integrity/ima/ima_template_lib.c create mode 100644 security/integrity/ima/ima_template_lib.h create mode 100644 security/keys/big_key.c create mode 100644 security/keys/persistent.c ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-19 12:20 ` James Morris @ 2013-11-22 4:22 ` Linus Torvalds 2013-11-22 9:36 ` James Morris ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Linus Torvalds @ 2013-11-22 4:22 UTC (permalink / raw) To: James Morris Cc: Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module, David Howells Ok, I've finally pulled this - at least tentatively (ie I have it on my machine, it's going through allmodconfig test-builds and I'll test booting asap, but I expect all that to succeed, and will push out the merge if/when it does so). However, I have to say, that pulling this was more than a little annoying. I would really have preferred seeing the key subsystem changes in a separate branch, to make it easier for me to do the "normal updates" first, and then do just the big changes separately. The key subsystem changes had absolutely _nothing_ in common with the rest of the security subsystem changes afaik. The fact that they got mixed up also made it all messier to go through, since there were (two sets of) fixes after the internal merges of the other security stuff - if the key subsystem changes had been a branch of its own, the fixes would have remained on that branch too. So for future cases: if there are big independent overhauls of core subsystems, I'd really like to see them kept separate, ok? Also, David, with (for example) 1700+ new lines in lib/assoc_array.c, I would really *really* like code like this to have some review by outsiders. Maybe you did have that, but I saw absolutely no sign of it in the tree when I merged it. That code alone made me go "Hmm, where did this come from, how was it tested, why should I merge it?". I do see *some* minimal comments on it from George Spelvin on lkml. I don't see any sign of that in the commit messages, though. I'd also see no comments on where the algorithm came from etc. It clearly has subtle memory ordering (smp_read_barrier_depends() etc), so I'm assuming it is based on something else or at least has some history to it. What is that history? In short: this is exactly the kind of thing I *don't* enjoy merging, because the code that needed review was - mixed up with other changes that had nothing to do with it - had no pointers to help me review it - had zero information about others who had possibly reviewed it before and quite frankly, without the extended explanation of what the changes were for (which I also didn't get initially), I'd probably have decided half-way that it's not worth the headache. In the end, the code didn't look bad, and I didn't find any obvious problems, but there's very much a reason why I merged this over two weeks after the first pull request was originally sent to me. So guys, make it easier for me to merge these kinds of things, and *don't* do what happened this time. Ok? Pretty please? Linus On Tue, Nov 19, 2013 at 4:20 AM, James Morris <jmorris@namei.org> wrote: > Also, here's an updated branch to pull from with four new fixes from > David. > > --- > > The following changes since commit be408cd3e1fef73e9408b196a79b9934697fe3b1: > > Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2013-11-04 06:40:55 -0800) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git for-linus2 ... ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-22 4:22 ` Linus Torvalds @ 2013-11-22 9:36 ` James Morris 2013-11-22 14:01 ` Josh Boyer 2013-11-22 20:25 ` David Howells 2 siblings, 0 replies; 14+ messages in thread From: James Morris @ 2013-11-22 9:36 UTC (permalink / raw) To: Linus Torvalds Cc: Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module, David Howells On Thu, 21 Nov 2013, Linus Torvalds wrote: > So for future cases: if there are big independent overhauls of core > subsystems, I'd really like to see them kept separate, ok? Yep. > So guys, make it easier for me to merge these kinds of things, and > *don't* do what happened this time. Ok? Pretty please? Ok. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-22 4:22 ` Linus Torvalds 2013-11-22 9:36 ` James Morris @ 2013-11-22 14:01 ` Josh Boyer 2013-11-22 20:25 ` David Howells 2 siblings, 0 replies; 14+ messages in thread From: Josh Boyer @ 2013-11-22 14:01 UTC (permalink / raw) To: Linus Torvalds Cc: James Morris, Linux-Kernel@Vger. Kernel. Org, linux-security-module, David Howells On Thu, Nov 21, 2013 at 11:22 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > In short: this is exactly the kind of thing I *don't* enjoy merging, > because the code that needed review was > > - mixed up with other changes that had nothing to do with it > - had no pointers to help me review it > - had zero information about others who had possibly reviewed it before > > and quite frankly, without the extended explanation of what the > changes were for (which I also didn't get initially), I'd probably > have decided half-way that it's not worth the headache. > > In the end, the code didn't look bad, and I didn't find any obvious > problems, but there's very much a reason why I merged this over two > weeks after the first pull request was originally sent to me. > > So guys, make it easier for me to merge these kinds of things, and > *don't* do what happened this time. Ok? Pretty please? If it makes you feel any more confident, we've been carrying the keys code during the development of Fedora 20 (and rawhide) as patches. They were needed to solve some issues some of the userspace people were seeing that David mentioned in his explanation. The issues that have cropped up were all fixed in the various follow up commits included in the pull and we haven't hit any others that I'm aware of. josh ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-22 4:22 ` Linus Torvalds 2013-11-22 9:36 ` James Morris 2013-11-22 14:01 ` Josh Boyer @ 2013-11-22 20:25 ` David Howells 2013-11-24 3:33 ` Linus Torvalds 2 siblings, 1 reply; 14+ messages in thread From: David Howells @ 2013-11-22 20:25 UTC (permalink / raw) To: Linus Torvalds, Paul E. McKenney, James Morris Cc: dhowells, Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module Linus Torvalds <torvalds@linux-foundation.org> wrote: > So for future cases: if there are big independent overhauls of core > subsystems, I'd really like to see them kept separate, ok? Since the trusted and encrypted keys that Mimi and Dmitry deal with are also more akin to the keyring stuff, should they go through the keyring branch? And does James want to hold that branch? > Also, David, with (for example) 1700+ new lines in lib/assoc_array.c, > I would really *really* like code like this to have some review by > outsiders. Maybe you did have that, but I saw absolutely no sign of it > in the tree when I merged it. That code alone made me go "Hmm, where > did this come from, how was it tested, why should I merge it?". I wrote it in userspace where I could easily drive it with huge numbers of entries (add a million keys, say, delete them randomly and check at each step that each remaining key can still be found) and also valground it. For reference, what's the best way of showing you something like this? I could include it in the commit message, but the driver is actually fairly large. Since it went through James's tree in the middle of a pile of patches, it would be awkward for you to then discard that information to trim things. I did show it to Paul McKenney - and he gave me some comments on it, though I didn't ask for a Reviewed-by line, which in retrospect I should've done. > I do see *some* minimal comments on it from George Spelvin on lkml. I don't > see any sign of that in the commit messages, though. Should we have a "Comments-from: x <y@z>" line for this? So that people who made comments but don't want to say they've properly reviewed it can be recognised formally? I'd prefer to avoid adding changelogs into the patch description - though maybe that's the best way to do this. > I'd also see no comments on where the algorithm came from etc. The basic algorithm was actually something I came up with myself to use on disk in one of the earliest implementations of fscache that I tried. I then adapted it to this. I suspected that I couldn't've been the only one to have thought this up, so I asked Paul to take a peek at the code and see what he thought. > It clearly has subtle memory ordering (smp_read_barrier_depends() etc), Actually, it's just where I'm doing RCU-type stuff. There's an argument I should be using the RCU functions anyway, but: (1) A flag would have to be passed down to say whether the callers of the assoc_array functions are holding the write lock or whether they're dependent on the RCU readlock - at least for the iterate and find functions. I suppose this flag would be ignored if LOCKDEP=n though the parameter would still have to exist. (2) Sometimes I want to read the pointers in a node and examine bit 0 (which is a tag to indicate metadata or leaf) and then decide what to do based on that. I don't want to interpolate a barrier there unless I'm actually going to follow the pointer and I don't want to have to read the pointer value again if I've determined it is what I'm looking for. For example: struct assoc_array_node *n1 = ...; struct assoc_array_node *n2 = rcu_access_pointer(n1->slots[x]); /* Did an ACCESS_ONCE() */ if (is_bit0_set(n2)) { /* Now we need a barrier */ n2 = rcu_dereference_check(n1->slots[x], check); /* Did another ACCESS_ONCE() */ } (3) I'm using the undefined struct assoc_array_ptr to prevent accidental dereferences of tagged pointers in the tree. Either Sparse or GCC will throw a errors if these are passed to rcu functions, depending on how you do it. > In short: this is exactly the kind of thing I *don't* enjoy merging, > because the code that needed review was > > - mixed up with other changes that had nothing to do with it > - had no pointers to help me review it > - had zero information about others who had possibly reviewed it before > > and quite frankly, without the extended explanation of what the > changes were for (which I also didn't get initially), I'd probably > have decided half-way that it's not worth the headache. Is there some way in the GIT repo to associate an 'extended explanation' with several patches? > In the end, the code didn't look bad, and I didn't find any obvious > problems, but there's very much a reason why I merged this over two > weeks after the first pull request was originally sent to me. > > So guys, make it easier for me to merge these kinds of things, and > *don't* do what happened this time. Ok? Pretty please? Ok. David ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-22 20:25 ` David Howells @ 2013-11-24 3:33 ` Linus Torvalds 2013-11-25 2:15 ` James Morris 0 siblings, 1 reply; 14+ messages in thread From: Linus Torvalds @ 2013-11-24 3:33 UTC (permalink / raw) To: David Howells Cc: Paul E. McKenney, James Morris, Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module On Fri, Nov 22, 2013 at 12:25 PM, David Howells <dhowells@redhat.com> wrote: > Linus Torvalds <torvalds@linux-foundation.org> wrote: > >> So for future cases: if there are big independent overhauls of core >> subsystems, I'd really like to see them kept separate, ok? > > Since the trusted and encrypted keys that Mimi and Dmitry deal with are also > more akin to the keyring stuff, should they go through the keyring branch? > And does James want to hold that branch? So by now, the changes are hopefully smaller and general "updates" rather than big new features. At that point, I don't care too deeply. It's the "this is a whole new big way of doing things, and there's fundamental new core code" that I would really like to be able to see separately in order to make it much easier for me to pull and walk through independently of the normal "updates to subsystem" stuff. > I wrote it in userspace where I could easily drive it with huge numbers of > entries (add a million keys, say, delete them randomly and check at each step > that each remaining key can still be found) and also valground it. For > reference, what's the best way of showing you something like this? Quite frankly, I just want to *know* about things like this, there doesn't have to be some fixed format for it. It can be part of the pull request, explaining where the code comes from, how it's been tested, who has looked at it etc etc. Or it can be just free-form in the commit messages. And again, this - for me - is about core code that isn't deeply embedded in some internal subsystem. So the reason I reacted to the assoc_array.c thing is that it was clearly set up to be generic, and it does end up being pretty different and affects "normal" users. So I go off looking for "ok, where can I find this discussed" for doing some minimal due diligence on a new set of core code, and I find very little on lkml, and nothing else. And the commit message talks about what it does, but not about the "who looked at it", so I basically had nothing to judge it by except just looking at the code. Which didn't look horrible, but it really would have made me happier hearing about people looking it over, and about you testing it in user space etc etc. > I did show it to Paul McKenney - and he gave me some comments on it, though I > didn't ask for a Reviewed-by line, which in retrospect I should've done. > > Should we have a "Comments-from: x <y@z>" line for this? So that people who > made comments but don't want to say they've properly reviewed it can be > recognised formally? A "reviewed-by" line is fine, but so is really just free-form explanations too. Not everything has to be a "xyz-by:" thing, especially things that are more important for one-time use at merge time rather than anything "this is a common pattern and people might want to do statistics about it over time". It's too late for this case, and for all I know there are no similar cases coming up in the security layer, but when I have something that ends up being pending for a two weeks, I want to at least try to educate people about *why* it was pending, and what I found difficult about the process. Maybe it happens again, maybe it won't. But if it does, we'll have at least spoken about the issues. > Is there some way in the GIT repo to associate an 'extended explanation' with > several patches? In theory, you can use notes, but I don't actually like it either technically _or_ from a "flow of information" standpoint, so I'd much rather see people try to note things in the commit messages, and then for the merge itself try to have explanations in the "please pull" message. Linus ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13 2013-11-24 3:33 ` Linus Torvalds @ 2013-11-25 2:15 ` James Morris 0 siblings, 0 replies; 14+ messages in thread From: James Morris @ 2013-11-25 2:15 UTC (permalink / raw) To: Linus Torvalds Cc: David Howells, Paul E. McKenney, Josh Boyer, Linux-Kernel@Vger. Kernel. Org, linux-security-module Sorry about all this -- we'll do better next time. -- James Morris <jmorris@namei.org> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [GIT] Security subsystem updates for 3.13
@ 2013-11-23 6:05 George Spelvin
0 siblings, 0 replies; 14+ messages in thread
From: George Spelvin @ 2013-11-23 6:05 UTC (permalink / raw)
To: dhowells, torvalds; +Cc: linux, linux-kernel, linux-security-module
On Thu, 21 Nov 2013, Linus Torvalds wrote:
> I do see *some* minimal comments on it from George Spelvin on lkml.
I'd like to apologize for dropping the ball on that. I started working
on it seriously, but with various emergencies, I've been AFK from lkml
for the last month.
I'm not really thilled with it; I think the fanout of 16 is low for
something with its scale ambitions, and the properties expected of the
chunked key access method are not documented as clearly as they should be.
The way the key is fiddled the put keyring objects in a contiguous
range of the trie is a particularly egregious layering violation.
But I am convinced that it's been tested and works; my complaints are
in the areas of ugliness and efficiency. And it's layered well enough that
it can be fixed later without radical sirgery.
^ permalink raw reply [flat|nested] 14+ messages in threadend of thread, other threads:[~2013-11-25 2:06 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-11-07 0:51 [GIT] Security subsystem updates for 3.13 James Morris 2013-11-18 15:31 ` Josh Boyer 2013-11-18 23:30 ` James Morris 2013-11-18 23:54 ` Linus Torvalds 2013-11-19 5:38 ` James Morris 2013-11-19 14:46 ` David Howells 2013-11-19 12:20 ` James Morris 2013-11-22 4:22 ` Linus Torvalds 2013-11-22 9:36 ` James Morris 2013-11-22 14:01 ` Josh Boyer 2013-11-22 20:25 ` David Howells 2013-11-24 3:33 ` Linus Torvalds 2013-11-25 2:15 ` James Morris -- strict thread matches above, loose matches on Subject: below -- 2013-11-23 6:05 George Spelvin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox