user/sven/linux.git/security/integrity, branch v4.7

security/integrity/ima/ima_policy.c: use %pU to output UUID in printable format

2016-05-21T00:58:30Z

Instead of open coded variant re-use extension that vsprintf.c provides us for ages. Signed-off-by: Andy Shevchenko Reviewed-by: Matt Fleming Cc: Dmitry Kasatkin Cc: Mimi Zohar Cc: Rasmus Villemoes Cc: Arnd Bergmann Cc: "Theodore Ts'o" Cc: Al Viro Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

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

2016-05-19T16:21:36Z

Pull security subsystem updates from James Morris: "Highlights: - A new LSM, "LoadPin", from Kees Cook is added, which allows forcing of modules and firmware to be loaded from a specific device (this is from ChromeOS, where the device as a whole is verified cryptographically via dm-verity). This is disabled by default but can be configured to be enabled by default (don't do this if you don't know what you're doing). - Keys: allow authentication data to be stored in an asymmetric key. Lots of general fixes and updates. - SELinux: add restrictions for loading of kernel modules via finit_module(). Distinguish non-init user namespace capability checks. Apply execstack check on thread stacks" * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (48 commits) LSM: LoadPin: provide enablement CONFIG Yama: use atomic allocations when reporting seccomp: Fix comment typo ima: add support for creating files using the mknodat syscall ima: fix ima_inode_post_setattr vfs: forbid write access when reading a file into memory fs: fix over-zealous use of "const" selinux: apply execstack check on thread stacks selinux: distinguish non-init user namespace capability checks LSM: LoadPin for kernel file loading restrictions fs: define a string representation of the kernel_read_file_id enumeration Yama: consolidate error reporting string_helpers: add kstrdup_quotable_file string_helpers: add kstrdup_quotable_cmdline string_helpers: add kstrdup_quotable selinux: check ss_initialized before revalidating an inode label selinux: delay inode label lookup as long as possible selinux: don't revalidate an inode's label when explicitly setting it selinux: Change bool variable name to index. KEYS: Add KEYCTL_DH_COMPUTE command ...

Merge branch 'work.const-path' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2016-05-17T21:41:03Z

Pull 'struct path' constification update from Al Viro: "'struct path' is passed by reference to a bunch of Linux security methods; in theory, there's nothing to stop them from modifying the damn thing and LSM community being what it is, sooner or later some enterprising soul is going to decide that it's a good idea. Let's remove the temptation and constify all of those..." * 'work.const-path' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: constify ima_d_path() constify security_sb_pivotroot() constify security_path_chroot() constify security_path_{link,rename} apparmor: remove useless checks for NULL ->mnt constify security_path_{mkdir,mknod,symlink} constify security_path_{unlink,rmdir} apparmor: constify common_perm_...() apparmor: constify aa_path_link() apparmor: new helper - common_path_perm() constify chmod_common/security_path_chmod constify security_sb_mount() constify chown_common/security_path_chown tomoyo: constify assorted struct path * apparmor_path_truncate(): path->mnt is never NULL constify vfs_truncate() constify security_path_truncate() [apparmor] constify struct path * in a bunch of helpers

Merge branch 'ovl-fixes' into for-linus

2016-05-17T06:17:59Z

Backmerge to resolve a conflict in ovl_lookup_real(); "ovl_lookup_real(): use lookup_one_len_unlocked()" instead, but it was too late in the cycle to rebase.

Merge tag 'keys-next-20160505' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into next

2016-05-05T23:29:00Z

Merge branch 'keys-trust' into keys-next

2016-05-04T16:20:20Z

Here's a set of patches that changes how certificates/keys are determined to be trusted. That's currently a two-step process: (1) Up until recently, when an X.509 certificate was parsed - no matter the source - it was judged against the keys in .system_keyring, assuming those keys to be trusted if they have KEY_FLAG_TRUSTED set upon them. This has just been changed such that any key in the .ima_mok keyring, if configured, may also be used to judge the trustworthiness of a new certificate, whether or not the .ima_mok keyring is meant to be consulted for whatever process is being undertaken. If a certificate is determined to be trustworthy, KEY_FLAG_TRUSTED will be set upon a key it is loaded into (if it is loaded into one), no matter what the key is going to be loaded for. (2) If an X.509 certificate is loaded into a key, then that key - if KEY_FLAG_TRUSTED gets set upon it - can be linked into any keyring with KEY_FLAG_TRUSTED_ONLY set upon it. This was meant to be the system keyring only, but has been extended to various IMA keyrings. A user can at will link any key marked KEY_FLAG_TRUSTED into any keyring marked KEY_FLAG_TRUSTED_ONLY if the relevant permissions masks permit it. These patches change that: (1) Trust becomes a matter of consulting the ring of trusted keys supplied when the trust is evaluated only. (2) Every keyring can be supplied with its own manager function to restrict what may be added to that keyring. This is called whenever a key is to be linked into the keyring to guard against a key being created in one keyring and then linked across. This function is supplied with the keyring and the key type and payload[*] of the key being linked in for use in its evaluation. It is permitted to use other data also, such as the contents of other keyrings such as the system keyrings. [*] The type and payload are supplied instead of a key because as an optimisation this function may be called whilst creating a key and so may reject the proposed key between preparse and allocation. (3) A default manager function is provided that permits keys to be restricted to only asymmetric keys that are vouched for by the contents of the system keyring. A second manager function is provided that just rejects with EPERM. (4) A key allocation flag, KEY_ALLOC_BYPASS_RESTRICTION, is made available so that the kernel can initialise keyrings with keys that form the root of the trust relationship. (5) KEY_FLAG_TRUSTED and KEY_FLAG_TRUSTED_ONLY are removed, along with key_preparsed_payload::trusted. This change also makes it possible in future for userspace to create a private set of trusted keys and then to have it sealed by setting a manager function where the private set is wholly independent of the kernel's trust relationships. Further changes in the set involve extracting certain IMA special keyrings and making them generally global: (*) .system_keyring is renamed to .builtin_trusted_keys and remains read only. It carries only keys built in to the kernel. It may be where UEFI keys should be loaded - though that could better be the new secondary keyring (see below) or a separate UEFI keyring. (*) An optional secondary system keyring (called .secondary_trusted_keys) is added to replace the IMA MOK keyring. (*) Keys can be added to the secondary keyring by root if the keys can be vouched for by either ring of system keys. (*) Module signing and kexec only use .builtin_trusted_keys and do not use the new secondary keyring. (*) Config option SYSTEM_TRUSTED_KEYS now depends on ASYMMETRIC_KEY_TYPE as that's the only type currently permitted on the system keyrings. (*) A new config option, IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY, is provided to allow keys to be added to IMA keyrings, subject to the restriction that such keys are validly signed by a key already in the system keyrings. If this option is enabled, but secondary keyrings aren't, additions to the IMA keyrings will be restricted to signatures verifiable by keys in the builtin system keyring only. Signed-off-by: David Howells

ima: fix the string representation of the LSM/IMA hook enumeration ordering

2016-05-04T08:46:00Z

This patch fixes the string representation of the LSM/IMA hook enumeration ordering used for displaying the IMA policy. Fixes: d9ddf077bb85 ("ima: support for kexec image and initramfs") Signed-off-by: Mimi Zohar Tested-by: Eric Richter Signed-off-by: James Morris

ima: add support for creating files using the mknodat syscall

2016-05-01T13:23:52Z

Commit 3034a14 "ima: pass 'opened' flag to identify newly created files" stopped identifying empty files as new files. However new empty files can be created using the mknodat syscall. On systems with IMA-appraisal enabled, these empty files are not labeled with security.ima extended attributes properly, preventing them from subsequently being opened in order to write the file data contents. This patch defines a new hook named ima_post_path_mknod() to mark these empty files, created using mknodat, as new in order to allow the file data contents to be written. In addition, files with security.ima xattrs containing a file signature are considered "immutable" and can not be modified. The file contents need to be written, before signing the file. This patch relaxes this requirement for new files, allowing the file signature to be written before the file contents. Changelog: - defer identifying files with signatures stored as security.ima (based on Dmitry Rozhkov's comments) - removing tests (eg. dentry, dentry->d_inode, inode->i_size == 0) (based on Al's review) Signed-off-by: Mimi Zohar Cc: Al Viro < Tested-by: Dmitry Rozhkov

ima: fix ima_inode_post_setattr

2016-05-01T13:23:52Z

Changing file metadata (eg. uid, guid) could result in having to re-appraise a file's integrity, but does not change the "new file" status nor the security.ima xattr. The IMA_PERMIT_DIRECTIO and IMA_DIGSIG_REQUIRED flags are policy rule specific. This patch only resets these flags, not the IMA_NEW_FILE or IMA_DIGSIG flags. With this patch, changing the file timestamp will not remove the file signature on new files. Reported-by: Dmitry Rozhkov Signed-off-by: Mimi Zohar Tested-by: Dmitry Rozhkov

security: integrity: Remove select to deleted option PUBLIC_KEY_ALGO_RSA

2016-04-12T18:54:58Z

Commit d43de6c780a8 ("akcipher: Move the RSA DER encoding check to the crypto layer") removed the Kconfig option PUBLIC_KEY_ALGO_RSA, but forgot to remove a 'select' to this option in the definition of INTEGRITY_ASYMMETRIC_KEYS. Let's remove the select, as it's ineffective now. Signed-off-by: Andreas Ziegler Signed-off-by: David Howells