* [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
` (2 more replies)
0 siblings, 3 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 12:20 ` James Morris
2013-11-19 14:46 ` David Howells
2 siblings, 0 replies; 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-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
2013-11-22 20:25 ` David Howells
2013-11-19 14:46 ` David Howells
2 siblings, 2 replies; 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-18 23:54 ` Linus Torvalds
2013-11-19 5:38 ` James Morris
2013-11-19 12:20 ` James Morris
@ 2013-11-19 14:46 ` David Howells
2 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-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
1 sibling, 2 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
1 sibling, 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
1 sibling, 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-19 12:20 ` James Morris
2013-11-22 4:22 ` Linus Torvalds
@ 2013-11-22 20:25 ` David Howells
2013-11-24 3:33 ` Linus Torvalds
1 sibling, 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 thread
end 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 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
2013-11-19 14:46 ` David Howells
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;
as well as URLs for NNTP newsgroup(s).