[GIT PULL] tpmdd updates for Linux 4.5
Hi Here are tpmdd updates for Linux 4.5. Sorry I didn't send this already last week but I had to hold until I get ack from Peter and Mimi before doing anything. Patches are quite well baked for a while now with the exception of small fix from Stefan to tpm_ibmvtpm, which I considered trivial enough to be included. Thanks, hope I did this right and apologies for the delay. /Jarkko The following changes since commit ebd68df3f24b318d391d15c458d6f43f340ba36a: Sync to Linus v4.4-rc2 for LSM developers. (2015-11-23 22:46:28 +1100) are available in the git repository at: https://github.com/jsakkine/linux-tpmdd.git tags/tpmdd-next-20151221 for you to fetch changes up to 5beb0c435bdde35a09376566b0e28f7df87c9f68: keys, trusted: seal with a TPM2 authorization policy (2015-12-20 15:27:13 +0200) tpmdd updates for Linux 4.5 Jarkko Sakkinen (3): keys, trusted: fix: *do not* allow duplicate key options keys, trusted: select hash algorithm for TPM2 chips keys, trusted: seal with a TPM2 authorization policy Jason Gunthorpe (6): tpm_tis: Use devm_free_irq not free_irq tpm_tis: Ensure interrupts are disabled when the driver starts tpm: rework tpm_get_timeouts() tpm_tis: Get rid of the duplicate IRQ probing code tpm_tis: Refactor the interrupt setup tpm_tis: Tighten IRQ auto-probing Martin Wilck (1): tpm_tis: further simplify calculation of ordinal duration Stefan Berger (1): tpm_ibmvtpm: properly handle interrupted packet receptions Documentation/security/keys-trusted-encrypted.txt | 31 ++- crypto/hash_info.c| 2 + drivers/char/tpm/tpm-interface.c | 23 +- drivers/char/tpm/tpm.h| 11 +- drivers/char/tpm/tpm2-cmd.c | 60 - drivers/char/tpm/tpm_crb.c| 14 +- drivers/char/tpm/tpm_ibmvtpm.c| 22 +- drivers/char/tpm/tpm_ibmvtpm.h| 1 + drivers/char/tpm/tpm_tis.c| 256 +- include/crypto/hash_info.h| 3 + include/keys/trusted-type.h | 5 + include/uapi/linux/hash_info.h| 1 + security/keys/Kconfig | 1 + security/keys/trusted.c | 56 - 14 files changed, 300 insertions(+), 186 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] linux-integrity changes for 4.5
Hi James, Lots of changes this time. This pull request adds support, by Dmitry Kasatkin, for: making the EVM keyring a trusted keyring, such that only keys signed by a key on the system keyring can be loaded onto the EVM keyring, loading the EVM keys onto the EVM trusted keyring by the kernel, enabling EVM when either the x509 or symmetric keys are available and loading the EVM symmetric key from hardware. As described by Mark Baushke and Petko Manalov at LSS 2015 in their talk "IMA/EVM: Real Applications for Embedded Networking Systems", this pull request includes support for two new IMA trusted keyrings named .ima_mok and .ima_blacklist. Keys being loaded on either the EVM or IMA trusted keyrings can be validated against either the system trusted keyring or the intermediary .ima_mok keyring and prevented from being loaded if on the .ima_blacklist keyring. Lastly, support for extending and displaying the IMA policy. Thanks! Mimi The following changes since commit ebd68df3f24b318d391d15c458d6f43f340ba36a: Sync to Linus v4.4-rc2 for LSM developers. (2015-11-23 22:46:28 +1100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git next for you to fetch changes up to 92cc916638a48f285736cd5541536e2e1b73ecf8: security/integrity: make ima/ima_mok.c explicitly non-modular (2015-12-15 10:01:43 -0500) Arnd Bergmann (1): evm: EVM_LOAD_X509 depends on EVM Dmitry Kasatkin (5): integrity: define '.evm' as a builtin 'trusted' keyring evm: load an x509 certificate from the kernel evm: enable EVM when X509 certificate is loaded evm: provide a function to set the EVM key from the kernel evm: reset EVM status when file attributes change Mimi Zohar (3): KEYS: prevent keys from being removed from specified keyrings IMA: prevent keys on the .ima_blacklist from being removed ima: update appraise flags after policy update completes Paul Gortmaker (1): security/integrity: make ima/ima_mok.c explicitly non-modular Petko Manolov (3): IMA: policy can now be updated multiple times IMA: create machine owner and blacklist keyrings IMA: allow reading back the current IMA policy crypto/asymmetric_keys/x509_public_key.c | 2 + include/keys/system_keyring.h| 24 +++ include/linux/evm.h | 7 + include/linux/key.h | 1 + security/integrity/Kconfig | 11 ++ security/integrity/digsig.c | 14 +- security/integrity/digsig_asymmetric.c | 14 ++ security/integrity/evm/Kconfig | 17 ++ security/integrity/evm/evm.h | 3 + security/integrity/evm/evm_crypto.c | 54 +- security/integrity/evm/evm_main.c| 32 +++- security/integrity/evm/evm_secfs.c | 12 +- security/integrity/iint.c| 1 + security/integrity/ima/Kconfig | 44 - security/integrity/ima/Makefile | 1 + security/integrity/ima/ima.h | 23 ++- security/integrity/ima/ima_fs.c | 42 - security/integrity/ima/ima_init.c| 2 +- security/integrity/ima/ima_mok.c | 55 ++ security/integrity/ima/ima_policy.c | 293 +++ security/integrity/integrity.h | 13 +- security/keys/key.c | 6 +- security/keys/keyctl.c | 56 -- 23 files changed, 643 insertions(+), 84 deletions(-) create mode 100644 security/integrity/ima/ima_mok.c -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] crypto: KEYS: convert public key to the akcipher api
Hi, On 12/19/2015 03:49 PM, kbuild test robot wrote: > Hi Tadeusz, > > [auto build test ERROR on crypto/master] > [also build test ERROR on v4.4-rc5 next-20151218] > > url: > https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-KEYS-convert-public-key-to-akcipher-api/20151213-103429 > base: > https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git master > config: x86_64-randconfig-s4-12200710 (attached as .config) > reproduce: > # save the attached .config to linux build tree > make ARCH=x86_64 > > All errors (new ones prefixed by >>): > >In file included from include/crypto/public_key.h:17:0, > from include/linux/verify_pefile.h:15, > from arch/x86/kernel/kexec-bzimage64.c:22: >include/keys/asymmetric-type.h: In function 'asymmetric_key_ids': >>> include/keys/asymmetric-type.h:74:12: error: dereferencing pointer to >>> incomplete type 'const struct key' > return key->payload.data[asym_key_ids]; >^ > > vim +74 include/keys/asymmetric-type.h > > 7901c1a8 David Howells 2014-09-16 68 > size_t len_1, > 7901c1a8 David Howells 2014-09-16 69 > const void *val_2, > 7901c1a8 David Howells 2014-09-16 70 > size_t len_2); > 146aa8b1 David Howells 2015-10-21 71 static inline > 146aa8b1 David Howells 2015-10-21 72 const struct asymmetric_key_ids > *asymmetric_key_ids(const struct key *key) > 146aa8b1 David Howells 2015-10-21 73 { > 146aa8b1 David Howells 2015-10-21 @74 return > key->payload.data[asym_key_ids]; > 146aa8b1 David Howells 2015-10-21 75 } > 7901c1a8 David Howells 2014-09-16 76 > 7901c1a8 David Howells 2014-09-16 77 /* > > :: The code at line 74 was first introduced by commit > :: 146aa8b1453bd8f1ff2304ffb71b4ee0eb9acdcc KEYS: Merge the type-specific > data with the payload data > > :: TO: David Howells > :: CC: David Howells > The previous patch was broken, re-sending again, sorry. I think there is something missing in this configuration. cat .config | grep KEXEC_BZIMAGE_VERIFY_SIG gives nothing. Anyways, this patch should fix it. ---8<--- From: Tadeusz Struk Fix auto build test ERROR on crypto/master Reported-by: Signed-off-by: Tadeusz Struk diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c index 0f8a6bb..23aa625 100644 --- a/arch/x86/kernel/kexec-bzimage64.c +++ b/arch/x86/kernel/kexec-bzimage64.c @@ -19,9 +19,10 @@ #include #include #include +#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG #include #include - +#endif #include #include #include -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 6/7] ima: measure and appraise the IMA policy itself
On Sun, Dec 20, 2015 at 12:11:04AM -0500, Mimi Zohar wrote: > On Thu, 2015-12-17 at 23:03 +0100, Luis R. Rodriguez wrote: > > On Tue, Dec 08, 2015 at 01:01:23PM -0500, Mimi Zohar wrote: > > > diff --git a/security/integrity/iint.c b/security/integrity/iint.c > > > index 8a45576..4d149c9 100644 > > > --- a/security/integrity/iint.c > > > +++ b/security/integrity/iint.c > > > @@ -222,6 +223,11 @@ int integrity_read_file(const char *path, char > > > **data) > > > return rc; > > > } > > > > > > + if (!S_ISREG(file_inode(file)->i_mode)) { > > > + rc = -EACCES; > > > + goto out; > > > + } > > > + > > > size = i_size_read(file_inode(file)); > > > if (size <= 0) > > > goto out; > > > > This hunk seems to be unrelated to this patch? If so can it be split out? > > Yes, sure. Up to now, 'cat' was used to load the IMA policy. A lot > of the problems related to opening and reading a file were hidden. So > besides making sure that only a regular file is opened, what other > things should we be checking? For example, do we permit the kernel to > read NFS mounted files? Should the kernel be limited to opening only > local files? Answering these questions becomes important as we move to > a single kernel file read function. Answering this properly should include effort to study and consolidate other kernel read routines. From the little that I've so far reviewed these we don't have much differences in requirements even between this IMA one and the sound one you just pointed out, the small changes for correctness however are important to capture for all. Because of this we should be able to still provide a generic read routine that takes all considerations into account, enables flexibility but more importantly shares the best practices for correctness. I can understand you might want to not wait for that yet, and I think that's fine, but lets work in parallel to make that happen. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 5/7] ima: measure and appraise firmware (improvement)
On Sat, Dec 19, 2015 at 11:44:41PM -0500, Mimi Zohar wrote: > On Thu, 2015-12-17 at 22:06 +0100, Luis R. Rodriguez wrote: > > On Tue, Dec 08, 2015 at 01:01:22PM -0500, Mimi Zohar wrote: > > > diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c > > > index 8524450..dcd902f 100644 > > > --- a/drivers/base/firmware_class.c > > > +++ b/drivers/base/firmware_class.c > > > @@ -29,6 +29,7 @@ > > > #include > > > #include > > > #include > > > +#include > > > > > > #include > > > > > > @@ -305,11 +306,17 @@ static int fw_read_file_contents(struct file *file, > > > struct firmware_buf *fw_buf) > > > buf = vmalloc(size); > > > if (!buf) > > > return -ENOMEM; > > > - rc = kernel_read(file, 0, buf, size); > > > - if (rc != size) { > > > - if (rc > 0) > > > - rc = -EIO; > > > + > > > + rc = ima_read_and_process_file(file, FIRMWARE_CHECK, buf, size); > > > + if (rc == -EIO) > > > goto fail; > > > + else if (rc != -EOPNOTSUPP) { > > > + rc = kernel_read(file, 0, buf, size); > > > + if (rc != size) { > > > + if (rc > 0) > > > + rc = -EIO; > > > + goto fail; > > > + } > > > } > > > rc = security_kernel_fw_from_file(file, buf, size); > > > if (rc) > > > > This is one way, the other way is to generalize the kernel-read from path > > routine. I have some changes which help generalize this routine a bit so > > help on review there would be appreciated. > > Sure. Where are the patches? http://lkml.kernel.org/r/1431996325-8840-2-git-send-email-mcg...@do-not-panic.com I'll post these in PATCH form now. > > I'm personally indifferent > > as to needing or not *now* a generic kernel read routine that is shared > > for this purpose *but* since this patch set *also* seems to be adding > > yet-another file reading I'm more inclined to wish for that to be addressed > > now instead. > > > > Please let me know if this logic is fair. > > Commit e3c4abb - "integrity: define a new function > integrity_read_file()" defined a method of reading a file from the > kernel. It's used to load an x509 key onto the IMA keyring for systems > without an initramfs. Dmitry's patch, included in this patch set, > calls this function to load the IMA policy as well. So this patch set > isn't defining a new function for reading a file from the kernel. It's > using an existing one. I see thanks, > FYI, sound/sound_firmware.c: do_mod_firmware_load() also reads a file. Thanks, this should be generalized as well the only reason for a different implementation I see here is the size constraint to 128k max. I think we can move that crap check out to take advantage of a common read. The integrity_read_file() seems rather generic as well and just skips locking checks and security checks, a generic solution doesn't have to happen now because as you note this has been in the kernel for a while. Eventually, once we generalize a common read perhaps we should stuff this into VFS common code and provide arguments to enable callers to provide restrictions or requirements. Let's work together on that after the holidays. Let's consolidate notes here: http://kernelnewbies.org/KernelProjects/common-kernel-loader Luis -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 3/7] ima: load policy using path
On Thu, Dec 17, 2015 at 11:33 AM, Luis R. Rodriguez wrote: > Please no, instead of adding yet-another kernel file-loading facility which is > likely error prone we should consolidate *all kernel file-loading facilities* > into a *common generic shared one*. So please work to make that happen since > you > need yet-another user for it.m.com > > Since you need yet-naother kernel file-loader please do the work to generalize > it, or at least try it. As per review in another thread with Mimi we determined they're not adding a *new* reader, but using an existing one. The possible issues with early read and pivot_root() as well as possible considerations for a common user mode helper are still relevant for when we generalize a common kernel loader. Mimi has also pointed out a few other kernel loaders. It seems we'll try to tackle this after the holidays. To help keep track of progress and consolidate notes on this I've stuffed details about this on this wiki: http://kernelnewbies.org/KernelProjects/common-kernel-loader Luis -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html