* Re: [PATCH v6 6/8] X.509: support OSCCA certificate parse
From: Vitaly Chikunov @ 2020-09-12 8:50 UTC (permalink / raw)
To: Tianjia Zhang
Cc: Herbert Xu, David S. Miller, David Howells, Maxime Coquelin,
Alexandre Torgue, James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Gilad Ben-Yossef, Pascal van Leeuwen,
linux-crypto, linux-kernel, keyrings, linux-stm32,
linux-arm-kernel, linux-security-module, Xufeng Zhang, Jia Zhang
In-Reply-To: <20200903131242.128665-7-tianjia.zhang@linux.alibaba.com>
On Thu, Sep 03, 2020 at 09:12:40PM +0800, Tianjia Zhang wrote:
> The digital certificate format based on SM2 crypto algorithm as
> specified in GM/T 0015-2012. It was published by State Encryption
> Management Bureau, China.
>
> This patch adds the OID object identifier defined by OSCCA. The
> x509 certificate supports sm2-with-sm3 type certificate parsing.
> It uses the standard elliptic curve public key, and the sm2
> algorithm signs the hash generated by sm3.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
> ---
> crypto/asymmetric_keys/x509_cert_parser.c | 14 +++++++++++++-
> include/linux/oid_registry.h | 6 ++++++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
> index 26ec20ef4899..6a8aee22bfd4 100644
> --- a/crypto/asymmetric_keys/x509_cert_parser.c
> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
> @@ -234,6 +234,10 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
> case OID_gost2012Signature512:
> ctx->cert->sig->hash_algo = "streebog512";
> goto ecrdsa;
> +
> + case OID_sm2_with_sm3:
> + ctx->cert->sig->hash_algo = "sm3";
> + goto sm2;
> }
>
> rsa_pkcs1:
> @@ -246,6 +250,11 @@ int x509_note_pkey_algo(void *context, size_t hdrlen,
> ctx->cert->sig->encoding = "raw";
> ctx->algo_oid = ctx->last_oid;
> return 0;
> +sm2:
> + ctx->cert->sig->pkey_algo = "sm2";
> + ctx->cert->sig->encoding = "raw";
> + ctx->algo_oid = ctx->last_oid;
> + return 0;
> }
>
> /*
> @@ -266,7 +275,8 @@ int x509_note_signature(void *context, size_t hdrlen,
> }
>
> if (strcmp(ctx->cert->sig->pkey_algo, "rsa") == 0 ||
> - strcmp(ctx->cert->sig->pkey_algo, "ecrdsa") == 0) {
> + strcmp(ctx->cert->sig->pkey_algo, "ecrdsa") == 0 ||
> + strcmp(ctx->cert->sig->pkey_algo, "sm2") == 0) {
> /* Discard the BIT STRING metadata */
> if (vlen < 1 || *(const u8 *)value != 0)
> return -EBADMSG;
> @@ -456,6 +466,8 @@ int x509_extract_key_data(void *context, size_t hdrlen,
> else if (ctx->last_oid == OID_gost2012PKey256 ||
> ctx->last_oid == OID_gost2012PKey512)
> ctx->cert->pub->pkey_algo = "ecrdsa";
> + else if (ctx->last_oid == OID_id_ecPublicKey)
> + ctx->cert->pub->pkey_algo = "sm2";
> else
> return -ENOPKG;
>
> diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
> index 657d6bf2c064..48fe3133ff39 100644
> --- a/include/linux/oid_registry.h
> +++ b/include/linux/oid_registry.h
> @@ -107,6 +107,12 @@ enum OID {
> OID_gostTC26Sign512B, /* 1.2.643.7.1.2.1.2.2 */
> OID_gostTC26Sign512C, /* 1.2.643.7.1.2.1.2.3 */
>
> + /* OSCCA */
> + OID_sm2, /* 1.2.156.10197.1.301 */
> + OID_sm3, /* 1.2.156.10197.1.401 */
> + OID_sm2_with_sm3, /* 1.2.156.10197.1.501 */
> + OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
OID_sm3WithRSAEncryption identifier is unused and this mode looks not
implemented. But, this is probably ok for possible future extension.
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Thanks,
> +
> OID__NR
> };
>
^ permalink raw reply
* Re: [PATCH v6 8/8] integrity: Asymmetric digsig supports SM2-with-SM3 algorithm
From: Vitaly Chikunov @ 2020-09-12 8:36 UTC (permalink / raw)
To: Tianjia Zhang
Cc: Herbert Xu, David S. Miller, David Howells, Maxime Coquelin,
Alexandre Torgue, James Morris, Serge E. Hallyn, Stephan Mueller,
Marcelo Henrique Cerri, Steven Rostedt (VMware), Masahiro Yamada,
Brendan Higgins, Andrew Morton, Johannes Weiner, Waiman Long,
Mimi Zohar, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Gilad Ben-Yossef, Pascal van Leeuwen,
linux-crypto, linux-kernel, keyrings, linux-stm32,
linux-arm-kernel, linux-security-module, Xufeng Zhang, Jia Zhang
In-Reply-To: <20200903131242.128665-9-tianjia.zhang@linux.alibaba.com>
On Thu, Sep 03, 2020 at 09:12:42PM +0800, Tianjia Zhang wrote:
> Asymmetric digsig supports SM2-with-SM3 algorithm combination,
> so that IMA can also verify SM2's signature data.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> (coding, not crypto
It looks not breaking ecrdsa/streebog handling and accords to rfc draft:
https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02
5.1.4.2. Hash Functions
The sm2 digital signature algorithm requires the hash functions
approved by Chinese Commercial Cryptography Administration Office,
such as sm3.
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Thanks,
> ---
> security/integrity/digsig_asymmetric.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index cfa4127d0518..b86a4a8f61ab 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -99,14 +99,22 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> memset(&pks, 0, sizeof(pks));
>
> pks.hash_algo = hash_algo_name[hdr->hash_algo];
> - if (hdr->hash_algo == HASH_ALGO_STREEBOG_256 ||
> - hdr->hash_algo == HASH_ALGO_STREEBOG_512) {
> + switch (hdr->hash_algo) {
> + case HASH_ALGO_STREEBOG_256:
> + case HASH_ALGO_STREEBOG_512:
> /* EC-RDSA and Streebog should go together. */
> pks.pkey_algo = "ecrdsa";
> pks.encoding = "raw";
> - } else {
> + break;
> + case HASH_ALGO_SM3_256:
> + /* SM2 and SM3 should go together. */
> + pks.pkey_algo = "sm2";
> + pks.encoding = "raw";
> + break;
> + default:
> pks.pkey_algo = "rsa";
> pks.encoding = "pkcs1";
> + break;
> }
> pks.digest = (u8 *)data;
> pks.digest_size = datalen;
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: Kees Cook @ 2020-09-12 7:56 UTC (permalink / raw)
To: James Morris
Cc: kernel-hardening, John Wood, Matthew Wilcox, Jonathan Corbet,
Alexander Viro, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Luis Chamberlain, Iurii Zaikin, Serge E. Hallyn,
linux-doc, linux-kernel, linux-fsdevel, linux-security-module
In-Reply-To: <alpine.LRH.2.21.2009121002100.17638@namei.org>
On Sat, Sep 12, 2020 at 10:03:23AM +1000, James Morris wrote:
> On Thu, 10 Sep 2020, Kees Cook wrote:
>
> > [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> > also visible at https://github.com/johwood/linux fbfam]
> >
> > From: John Wood <john.wood@gmx.com>
>
> Why are you resending this? The author of the code needs to be able to
> send and receive emails directly as part of development and maintenance.
I wanted to flush it from my "review" TODO list, mainly.
--
Kees Cook
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: Kees Cook @ 2020-09-12 7:55 UTC (permalink / raw)
To: John Wood
Cc: Jann Horn, Matthew Wilcox, Jonathan Corbet, Alexander Viro,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Luis Chamberlain, Iurii Zaikin, James Morris, Serge E. Hallyn,
linux-doc, linux-kernel, linux-fsdevel, linux-security-module
In-Reply-To: <20200911144806.GA4128@ubuntu>
On Fri, Sep 11, 2020 at 04:48:06PM +0200, John Wood wrote:
> In other words, a late reply to this serie comments is not a lack of
> interest. Moreover, I think it would be better that I try to understand and
> to implement your ideas before anything else.
Understood! :)
> My original patch serie is composed of 9 patches, so the 3 lasts are lost.
> Kees: Have you removed them for some reason? Can you send them for review?
>
> security/fbfam: Add two new prctls to enable and disable the fbfam feature
> https://github.com/johwood/linux/commit/8a36399847213e7eb7b45b853568a53666bd0083
>
> Documentation/security: Add documentation for the fbfam feature
> https://github.com/johwood/linux/commit/fb46804541f5c0915f3f48acefbe6dc998815609
>
> MAINTAINERS: Add a new entry for the fbfam feature
> https://github.com/johwood/linux/commit/4303bc8935334136c6ef47b5e50b87cd2c472c1f
Oh, hm, I'm not sure where they went. I think they were missing from my
inbox when I saved your series from email. An oversight on my part;
apologies!
> Is there a problem if I ask for some guidance (replying to this thread)
> during the process to do my second patch series?
Please feel free! I'm happy to help. :)
> My goal is to learn as much as possible doing something useful for the
> linux kernel.
Sounds good; thanks!
--
Kees Cook
^ permalink raw reply
* Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)
From: James Morris @ 2020-09-12 0:28 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Mickaël Salaün, Mimi Zohar, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Al Viro, Andrew Morton, Andy Lutomirski,
Arnd Bergmann, Casey Schaufler, Christian Brauner,
Christian Heimes, Daniel Borkmann, Deven Bowers, Dmitry Vyukov,
Eric Biggers, Eric Chiang, Florian Weimer, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Lakshmi Ramasubramanian,
Matthew Garrett, Michael Kerrisk, Miklos Szeredi,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Steve Dower, Steve Grubb, Tetsuo Handa,
Thibaut Sautereau, Vincent Strubel, kernel-hardening, linux-api,
linux-integrity, linux-security-module, linux-fsdevel
In-Reply-To: <20200910184033.GX6583@casper.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
On Thu, 10 Sep 2020, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
> > There is also the use case of noexec mounts and file permissions. From
> > user space point of view, it doesn't matter which kernel component is in
> > charge of defining the policy. The syscall should then not be tied with
> > a verification/integrity/signature/appraisal vocabulary, but simply an
> > access control one.
>
> permission()?
>
The caller is not asking the kernel to grant permission, it's asking
"SHOULD I access this file?"
The caller doesn't know, for example, if the script file it's about to
execute has been signed, or if it's from a noexec mount. It's asking the
kernel, which does know. (Note that this could also be extended to reading
configuration files).
How about: should_faccessat ?
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RFC PATCH v8 0/3] Add support for AT_INTERPRETED (was O_MAYEXEC)
From: James Morris @ 2020-09-12 0:16 UTC (permalink / raw)
To: Al Viro
Cc: Mickaël Salaün, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Andrew Morton, Andy Lutomirski,
Christian Brauner, Christian Heimes, Daniel Borkmann,
Deven Bowers, Dmitry Vyukov, Eric Biggers, Eric Chiang,
Florian Weimer, Jan Kara, Jann Horn, Jonathan Corbet, Kees Cook,
Lakshmi Ramasubramanian, Matthew Garrett, Matthew Wilcox,
Michael Kerrisk, Miklos Szeredi, Mimi Zohar,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Steve Dower, Steve Grubb, Tetsuo Handa,
Thibaut Sautereau, Vincent Strubel, kernel-hardening, linux-api,
linux-integrity, linux-security-module, linux-fsdevel
In-Reply-To: <20200909171316.GW1236603@ZenIV.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]
On Wed, 9 Sep 2020, Al Viro wrote:
> On Wed, Sep 09, 2020 at 09:19:11AM +0200, Mickaël Salaün wrote:
> >
> > On 08/09/2020 20:50, Al Viro wrote:
> > > On Tue, Sep 08, 2020 at 09:59:53AM +0200, Mickaël Salaün wrote:
> > >> Hi,
> > >>
> > >> This height patch series rework the previous O_MAYEXEC series by not
> > >> adding a new flag to openat2(2) but to faccessat2(2) instead. As
> > >> suggested, this enables to perform the access check on a file descriptor
> > >> instead of on a file path (while opening it). This may require two
> > >> checks (one on open and then with faccessat2) but it is a more generic
> > >> approach [8].
> > >
> > > Again, why is that folded into lookup/open/whatnot, rather than being
> > > an operation applied to a file (e.g. O_PATH one)?
> > >
> >
> > I don't understand your question. AT_INTERPRETED can and should be used
> > with AT_EMPTY_PATH. The two checks I wrote about was for IMA.
>
> Once more, with feeling: don't hide that behind existing syscalls.
> If you want to tell LSM have a look at given fs object in a special
> way, *add* *a* *new* *system* *call* *for* *doing* *just* *that*.
It's not just for LSM, though, and it has identical semantics from the
caller's POV as faccessat().
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: James Morris @ 2020-09-12 0:03 UTC (permalink / raw)
To: Kees Cook
Cc: kernel-hardening, John Wood, Matthew Wilcox, Jonathan Corbet,
Alexander Viro, Ingo Molnar, Peter Zijlstra, Juri Lelli,
Vincent Guittot, Dietmar Eggemann, Steven Rostedt, Ben Segall,
Mel Gorman, Luis Chamberlain, Iurii Zaikin, Serge E. Hallyn,
linux-doc, linux-kernel, linux-fsdevel, linux-security-module
In-Reply-To: <20200910202107.3799376-1-keescook@chromium.org>
On Thu, 10 Sep 2020, Kees Cook wrote:
> [kees: re-sending this series on behalf of John Wood <john.wood@gmx.com>
> also visible at https://github.com/johwood/linux fbfam]
>
> From: John Wood <john.wood@gmx.com>
Why are you resending this? The author of the code needs to be able to
send and receive emails directly as part of development and maintenance.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine
From: Lenny Szubowicz @ 2020-09-11 19:46 UTC (permalink / raw)
To: Mimi Zohar, Ard Biesheuvel
Cc: Linux Kernel Mailing List, linux-efi, platform-driver-x86,
linux-security-module, andy.shevchenko, James Morris, serge,
Kees Cook, Borislav Petkov, Peter Jones, David Howells, prarit
In-Reply-To: <06ea64fec71ebd18f0c5ed6b0d9b5a7d8f1d4775.camel@linux.ibm.com>
On 9/11/20 3:08 PM, Mimi Zohar wrote:
> On Fri, 2020-09-11 at 21:16 +0300, Ard Biesheuvel wrote:
>> I think we can just merge the patches as they are, with Mimi's R-b carried over.
>
> Other than the comments beginning on the "/*" line as opposed to the
> subsequent line, the updated 2/2 and 3/3 patches look fine.
>
> thanks,
>
> Mimi
>
I also prefer the block comment style that you are suggesting. However, I
kept to the style used by the load_uefi.c source file. If checkpatch.pl
considers it acceptable, I deferred to consistency within the source module.
-Lenny.
^ permalink raw reply
* Re: [PATCH] socket.7,unix.7: add initial description for SO_PEERSEC
From: Stephen Smalley @ 2020-09-11 19:33 UTC (permalink / raw)
To: Michael Kerrisk; +Cc: linux-man, LSM List, SElinux list
In-Reply-To: <20200910210059.34759-1-stephen.smalley.work@gmail.com>
On Thu, Sep 10, 2020 at 5:01 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> SO_PEERSEC was introduced for AF_UNIX stream sockets connected via
> connect(2) in Linux 2.6.2 and later augmented to support AF_UNIX stream
> and datagram sockets created via socketpair(2) in Linux 4.18. Document
> SO_PEERSEC in the socket.7 and unix.7 man pages following the example
> of the existing SO_PEERCRED descriptions. SO_PEERSEC is also supported
> on AF_INET sockets when using labeled IPSEC or NetLabel but defer
> adding a description of that support to a separate patch.
>
> Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Here are the relevant commits introducing SO_PEERSEC and the
socketpair support (the first one is from the pre-git history tree
since it predates git):
https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=da6e57a2e6bd7939f610d957afacaf6a131e75ed
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0b811db2cb2aabc910e53d34ebb95a15997c33e7
Can add those into the commit message. Not sure if you want them in
the man pages themselves (especially the first pre-git one).
^ permalink raw reply
* Re: [PATCH v6 8/8] integrity: Asymmetric digsig supports SM2-with-SM3 algorithm
From: Mimi Zohar @ 2020-09-11 19:22 UTC (permalink / raw)
To: Tianjia Zhang, Herbert Xu, David S. Miller, David Howells,
Maxime Coquelin, Alexandre Torgue, James Morris, Serge E. Hallyn,
Stephan Mueller, Marcelo Henrique Cerri, Steven Rostedt (VMware),
Masahiro Yamada, Brendan Higgins, Andrew Morton, Johannes Weiner,
Waiman Long, Lakshmi Ramasubramanian, Colin Ian King,
Tushar Sugandhi, Vitaly Chikunov, Gilad Ben-Yossef,
Pascal van Leeuwen, linux-crypto, linux-kernel, keyrings,
linux-stm32, linux-arm-kernel, linux-security-module
Cc: Xufeng Zhang, Jia Zhang
In-Reply-To: <20200903131242.128665-9-tianjia.zhang@linux.alibaba.com>
On Thu, 2020-09-03 at 21:12 +0800, Tianjia Zhang wrote:
> Asymmetric digsig supports SM2-with-SM3 algorithm combination,
> so that IMA can also verify SM2's signature data.
>
> Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
> Tested-by: Xufeng Zhang <yunbo.xufeng@linux.alibaba.com>
Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> (coding, not crypto
perspective)
> ---
> security/integrity/digsig_asymmetric.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/security/integrity/digsig_asymmetric.c b/security/integrity/digsig_asymmetric.c
> index cfa4127d0518..b86a4a8f61ab 100644
> --- a/security/integrity/digsig_asymmetric.c
> +++ b/security/integrity/digsig_asymmetric.c
> @@ -99,14 +99,22 @@ int asymmetric_verify(struct key *keyring, const char *sig,
> memset(&pks, 0, sizeof(pks));
>
> pks.hash_algo = hash_algo_name[hdr->hash_algo];
> - if (hdr->hash_algo == HASH_ALGO_STREEBOG_256 ||
> - hdr->hash_algo == HASH_ALGO_STREEBOG_512) {
> + switch (hdr->hash_algo) {
> + case HASH_ALGO_STREEBOG_256:
> + case HASH_ALGO_STREEBOG_512:
> /* EC-RDSA and Streebog should go together. */
> pks.pkey_algo = "ecrdsa";
> pks.encoding = "raw";
> - } else {
> + break;
> + case HASH_ALGO_SM3_256:
> + /* SM2 and SM3 should go together. */
> + pks.pkey_algo = "sm2";
> + pks.encoding = "raw";
> + break;
> + default:
> pks.pkey_algo = "rsa";
> pks.encoding = "pkcs1";
> + break;
> }
> pks.digest = (u8 *)data;
> pks.digest_size = datalen;
^ permalink raw reply
* Re: [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine
From: Mimi Zohar @ 2020-09-11 19:08 UTC (permalink / raw)
To: Ard Biesheuvel, Lenny Szubowicz
Cc: Linux Kernel Mailing List, linux-efi, platform-driver-x86,
linux-security-module, andy.shevchenko, James Morris, serge,
Kees Cook, Borislav Petkov, Peter Jones, David Howells, prarit
In-Reply-To: <CAMj1kXEz8y+X6KjqWWFD=38dDowqXDBvnPbgeh30+o83KpmKrg@mail.gmail.com>
On Fri, 2020-09-11 at 21:16 +0300, Ard Biesheuvel wrote:
> I think we can just merge the patches as they are, with Mimi's R-b carried over.
Other than the comments beginning on the "/*" line as opposed to the
subsequent line, the updated 2/2 and 3/3 patches look fine.
thanks,
Mimi
^ permalink raw reply
* [Spam] We are still waiting for your email...
From: piyin.crhe @ 2020-09-09 8:49 UTC (permalink / raw)
To: linux-security-module
Dear Beneficiary,
We wish to inform you that a power of attorney was forwarded to
our office by two gentlemen regarding your unclaimed fund of $56
Million Dollar. One of them is an American citizen named Mr.
Robert Porter and the other is Mr. Wilhelm Berg a Swedish
citizen.We have be waiting for you to contact us since last year.
The document claims these gentlemen to be your authorized
representatives, and the power of attorney states that you are
already deceased. It further states that your death was due to
lung cancer, with your date of death being January 27th, 2020.
They have now submitted a new account to replace the receiving
account that was in the original claim of funds. These funds have
remained unclaimed for quite some time and the need for
resolution is pressing. Below is the new account they have
submitted.
Account Name's : Robert Porter /Wilhelm Berg
Account: 5007-29 438 66
IBAN-nr: SE4150000000050072943866
Bic-kod: ESSESESS
Skandinaviska Enskilda Banken. (SEB :)
SWEDEN .
In the event that you are in fact still alive, we ask that you
confirm your existence by responding to this email. You are to
view this as a matter requiring immediate attention and response.
We have 48 hr monitoring of all activities within Federal Reserve
Bank.On this regard,you will be directed to any of our office
center that you will go in person to sign the final papers,
because we have our payment center in Europe,Asia,America and
Canada.You will go to any of the office that you will be directed
to with the copy of the documents of your fund.
We have contacted the bank in the Sweden asking them to wait for
further directives from Federal Reserve Bank, prior to
authorizing any withdrawals in any form. Our request is based
entirely on our attempt to verify that you are in fact deceased,
before money is wrongly disbursed.
Your in Service,
Robert Steven Kaplan
2200 N Pearl St, Dallas, TX 75201, United States
^ permalink raw reply
* [PATCH v3] certs: Add EFI_CERT_X509_GUID support for dbx entries
From: Eric Snowberg @ 2020-09-11 18:22 UTC (permalink / raw)
To: dhowells, dwmw2, jarkko.sakkinen
Cc: jmorris, serge, nayna, erichte, mpe, zohar, eric.snowberg,
keyrings, linux-kernel, linux-security-module, rdunlap
The Secure Boot Forbidden Signature Database, dbx, contains a list of now
revoked signatures and keys previously approved to boot with UEFI Secure
Boot enabled. The dbx is capable of containing any number of
EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID
entries.
Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries are
skipped.
Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID
is found, it is added as an asymmetrical key to the .blacklist keyring.
Anytime the .platform keyring is used, the keys in the .blacklist keyring
are referenced, if a matching key is found, the key will be rejected.
Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
---
v3:
Fixed an issue when CONFIG_PKCS7_MESSAGE_PARSER is not builtin and defined
as a module instead, pointed out by Randy Dunlap
v2:
Fixed build issue reported by kernel test robot <lkp@intel.com>
Commit message update (suggested by Jarkko Sakkinen)
---
certs/blacklist.c | 33 +++++++++++++++++++
certs/blacklist.h | 12 +++++++
certs/system_keyring.c | 6 ++++
include/keys/system_keyring.h | 11 +++++++
.../platform_certs/keyring_handler.c | 11 +++++++
5 files changed, 73 insertions(+)
diff --git a/certs/blacklist.c b/certs/blacklist.c
index 6514f9ebc943..3d1514ba5d47 100644
--- a/certs/blacklist.c
+++ b/certs/blacklist.c
@@ -100,6 +100,39 @@ int mark_hash_blacklisted(const char *hash)
return 0;
}
+int mark_key_revocationlisted(const char *data, size_t size)
+{
+ key_ref_t key;
+
+ key = key_create_or_update(make_key_ref(blacklist_keyring, true),
+ "asymmetric",
+ NULL,
+ data,
+ size,
+ ((KEY_POS_ALL & ~KEY_POS_SETATTR) | KEY_USR_VIEW),
+ KEY_ALLOC_NOT_IN_QUOTA | KEY_ALLOC_BUILT_IN);
+
+ if (IS_ERR(key)) {
+ pr_err("Problem with revocation key (%ld)\n", PTR_ERR(key));
+ return PTR_ERR(key);
+ }
+
+ return 0;
+}
+
+int is_key_revocationlisted(struct pkcs7_message *pkcs7)
+{
+ int ret;
+
+ ret = validate_trust(pkcs7, blacklist_keyring);
+
+ if (ret == 0)
+ return -EKEYREJECTED;
+
+ return -ENOKEY;
+}
+EXPORT_SYMBOL_GPL(is_key_revocationlisted);
+
/**
* is_hash_blacklisted - Determine if a hash is blacklisted
* @hash: The hash to be checked as a binary blob
diff --git a/certs/blacklist.h b/certs/blacklist.h
index 1efd6fa0dc60..420bb7c86e07 100644
--- a/certs/blacklist.h
+++ b/certs/blacklist.h
@@ -1,3 +1,15 @@
#include <linux/kernel.h>
+#include <linux/errno.h>
+#include <crypto/pkcs7.h>
extern const char __initconst *const blacklist_hashes[];
+
+#ifdef CONFIG_INTEGRITY_PLATFORM_KEYRING
+#define validate_trust pkcs7_validate_trust
+#else
+static inline int validate_trust(struct pkcs7_message *pkcs7,
+ struct key *trust_keyring)
+{
+ return -ENOKEY;
+}
+#endif
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 798291177186..f8ea96219155 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -241,6 +241,12 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
pr_devel("PKCS#7 platform keyring is not available\n");
goto error;
}
+
+ ret = is_key_revocationlisted(pkcs7);
+ if (ret != -ENOKEY) {
+ pr_devel("PKCS#7 platform key revocationlisted\n");
+ goto error;
+ }
}
ret = pkcs7_validate_trust(pkcs7, trusted_keys);
if (ret < 0) {
diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index fb8b07daa9d1..b6991cfe1b6d 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -31,11 +31,14 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
#define restrict_link_by_builtin_and_secondary_trusted restrict_link_by_builtin_trusted
#endif
+extern struct pkcs7_message *pkcs7;
#ifdef CONFIG_SYSTEM_BLACKLIST_KEYRING
extern int mark_hash_blacklisted(const char *hash);
+extern int mark_key_revocationlisted(const char *data, size_t size);
extern int is_hash_blacklisted(const u8 *hash, size_t hash_len,
const char *type);
extern int is_binary_blacklisted(const u8 *hash, size_t hash_len);
+extern int is_key_revocationlisted(struct pkcs7_message *pkcs7);
#else
static inline int is_hash_blacklisted(const u8 *hash, size_t hash_len,
const char *type)
@@ -47,6 +50,14 @@ static inline int is_binary_blacklisted(const u8 *hash, size_t hash_len)
{
return 0;
}
+static inline int mark_key_revocationlisted(const char *data, size_t size)
+{
+ return 0;
+}
+static inline int is_key_revocationlisted(struct pkcs7_message *pkcs7)
+{
+ return -ENOKEY;
+}
#endif
#ifdef CONFIG_IMA_BLACKLIST_KEYRING
diff --git a/security/integrity/platform_certs/keyring_handler.c b/security/integrity/platform_certs/keyring_handler.c
index c5ba695c10e3..cc5a43804bc4 100644
--- a/security/integrity/platform_certs/keyring_handler.c
+++ b/security/integrity/platform_certs/keyring_handler.c
@@ -55,6 +55,15 @@ static __init void uefi_blacklist_binary(const char *source,
uefi_blacklist_hash(source, data, len, "bin:", 4);
}
+/*
+ * Revocationlist the X509 cert
+ */
+static __init void uefi_revocationlist_x509(const char *source,
+ const void *data, size_t len)
+{
+ mark_key_revocationlisted(data, len);
+}
+
/*
* Return the appropriate handler for particular signature list types found in
* the UEFI db and MokListRT tables.
@@ -76,5 +85,7 @@ __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type)
return uefi_blacklist_x509_tbs;
if (efi_guidcmp(*sig_type, efi_cert_sha256_guid) == 0)
return uefi_blacklist_binary;
+ if (efi_guidcmp(*sig_type, efi_cert_x509_guid) == 0)
+ return uefi_revocationlist_x509;
return 0;
}
--
2.18.1
^ permalink raw reply related
* Re: [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine
From: Ard Biesheuvel @ 2020-09-11 18:16 UTC (permalink / raw)
To: Lenny Szubowicz
Cc: Mimi Zohar, Linux Kernel Mailing List, linux-efi,
platform-driver-x86, linux-security-module, andy.shevchenko,
James Morris, serge, Kees Cook, Borislav Petkov, Peter Jones,
David Howells, prarit
In-Reply-To: <394190b9-59bd-5cb3-317e-736852f190f4@redhat.com>
On Fri, 11 Sep 2020 at 20:18, Lenny Szubowicz <lszubowi@redhat.com> wrote:
>
> On 9/11/20 11:59 AM, Mimi Zohar wrote:
> > On Fri, 2020-09-11 at 11:54 -0400, Lenny Szubowicz wrote:
> >> On 9/11/20 11:02 AM, Ard Biesheuvel wrote:
> >>> On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz <lszubowi@redhat.com> wrote:
> >>>>
> >>>> Move the loading of certs from the UEFI MokListRT into a separate
> >>>> routine to facilitate additional MokList functionality.
> >>>>
> >>>> There is no visible functional change as a result of this patch.
> >>>> Although the UEFI dbx certs are now loaded before the MokList certs,
> >>>> they are loaded onto different key rings. So the order of the keys
> >>>> on their respective key rings is the same.
> >>>>
> >>>> Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
> >>>
> >>> Why did you drop Mimi's reviewed-by from this patch?
> >>
> >> It was not intentional. I was just not aware that I needed to propagate
> >> Mimi Zohar's reviewed-by from V1 of the patch to V2.
> >>
> >> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
> >>
> >> V2 includes changes in that patch to incorporate suggestions from
> >> Andy Shevchenko. My assumption was that the maintainer would
> >> gather up the reviewed-by and add any signed-off-by as appropriate,
> >> but it sounds like my assumption was incorrect. In retrospect, I
> >> could see that having the maintainer dig through prior versions
> >> of a patch set for prior reviewed-by tags could be burdensome.
> >
> > As much as possible moving code should be done without making changes,
> > simpler for code review. Then as a separate patch you make changes.
> > That way you could also have retained my Reviewed-by.
> >
> > Mimi
>
> If you or Ard think I should, I can do a V3 with:
>
> Patch V3 01: Unchanged from V2
> Patch V3 02: Goes back to V1 of patch 02 that Mimi reviewed
> Patch V3 03: New. Has Andy's cleanup suggestions separated from patch 02
> Patch V3 04: This would most probably just be the V2 of patch 03 with no changes
>
I think we can just merge the patches as they are, with Mimi's R-b carried over.
^ permalink raw reply
* [PATCH v37 15/24] x86/sgx: Enable provisioning for remote attestation
From: Jarkko Sakkinen @ 2020-09-11 12:40 UTC (permalink / raw)
To: x86, linux-sgx
Cc: linux-kernel, Jarkko Sakkinen, linux-security-module,
Jethro Beekman, Darren Kenny, Andy Lutomirski, akpm,
andriy.shevchenko, asapek, bp, cedric.xing, chenalexchen,
conradparker, cyhanish, dave.hansen, haitao.huang, josh,
kai.huang, kai.svahn, kmoy, ludloff, nhorman, npmccallum,
puiterwijk, rientjes, sean.j.christopherson, tglx, yaozhangx
In-Reply-To: <20200911124019.42178-1-jarkko.sakkinen@linux.intel.com>
Provisioning Certification Enclave (PCE), the root of trust for other
enclaves, generates a signing key from a fused key called Provisioning
Certification Key. PCE can then use this key to certify an attestation key
of a Quoting Enclave (QE), e.g. we get the chain of trust down to the
hardware if the Intel signed PCE is used.
To use the needed keys, ATTRIBUTE.PROVISIONKEY is required but should be
only allowed for those who actually need it so that only the trusted
parties can certify QE's.
Obviously the attestation service should know the public key of the used
PCE and that way detect illegit attestation, but whitelisting the legit
users still adds an additional layer of defence.
Add new device file called /dev/sgx/provision. The sole purpose of this
file is to provide file descriptors that act as privilege tokens to allow
to build enclaves with ATTRIBUTE.PROVISIONKEY set. A new ioctl called
SGX_IOC_ENCLAVE_PROVISION is used to assign this token to an enclave.
Cc: linux-security-module@vger.kernel.org
Acked-by: Jethro Beekman <jethro@fortanix.com>
Reviewed-by: Darren Kenny <darren.kenny@oracle.com>
Suggested-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
arch/x86/include/uapi/asm/sgx.h | 11 ++++++++
arch/x86/kernel/cpu/sgx/driver.c | 18 ++++++++++++
arch/x86/kernel/cpu/sgx/driver.h | 2 ++
arch/x86/kernel/cpu/sgx/ioctl.c | 47 ++++++++++++++++++++++++++++++++
4 files changed, 78 insertions(+)
diff --git a/arch/x86/include/uapi/asm/sgx.h b/arch/x86/include/uapi/asm/sgx.h
index 7729730d8580..d0916fb9629e 100644
--- a/arch/x86/include/uapi/asm/sgx.h
+++ b/arch/x86/include/uapi/asm/sgx.h
@@ -25,6 +25,8 @@ enum sgx_page_flags {
_IOWR(SGX_MAGIC, 0x01, struct sgx_enclave_add_pages)
#define SGX_IOC_ENCLAVE_INIT \
_IOW(SGX_MAGIC, 0x02, struct sgx_enclave_init)
+#define SGX_IOC_ENCLAVE_PROVISION \
+ _IOW(SGX_MAGIC, 0x03, struct sgx_enclave_provision)
/**
* struct sgx_enclave_create - parameter structure for the
@@ -61,4 +63,13 @@ struct sgx_enclave_init {
__u64 sigstruct;
};
+/**
+ * struct sgx_enclave_provision - parameter structure for the
+ * %SGX_IOC_ENCLAVE_PROVISION ioctl
+ * @attribute_fd: file handle of the attribute file in the securityfs
+ */
+struct sgx_enclave_provision {
+ __u64 attribute_fd;
+};
+
#endif /* _UAPI_ASM_X86_SGX_H */
diff --git a/arch/x86/kernel/cpu/sgx/driver.c b/arch/x86/kernel/cpu/sgx/driver.c
index 7bdb49dfcca6..d01b28f7ce4a 100644
--- a/arch/x86/kernel/cpu/sgx/driver.c
+++ b/arch/x86/kernel/cpu/sgx/driver.c
@@ -134,6 +134,10 @@ static const struct file_operations sgx_encl_fops = {
.get_unmapped_area = sgx_get_unmapped_area,
};
+const struct file_operations sgx_provision_fops = {
+ .owner = THIS_MODULE,
+};
+
static struct miscdevice sgx_dev_enclave = {
.minor = MISC_DYNAMIC_MINOR,
.name = "enclave",
@@ -141,6 +145,13 @@ static struct miscdevice sgx_dev_enclave = {
.fops = &sgx_encl_fops,
};
+static struct miscdevice sgx_dev_provision = {
+ .minor = MISC_DYNAMIC_MINOR,
+ .name = "provision",
+ .nodename = "sgx/provision",
+ .fops = &sgx_provision_fops,
+};
+
int __init sgx_drv_init(void)
{
unsigned int eax, ebx, ecx, edx;
@@ -181,5 +192,12 @@ int __init sgx_drv_init(void)
return ret;
}
+ ret = misc_register(&sgx_dev_provision);
+ if (ret) {
+ pr_err("Creating /dev/sgx/provision failed with %d.\n", ret);
+ misc_deregister(&sgx_dev_enclave);
+ return ret;
+ }
+
return 0;
}
diff --git a/arch/x86/kernel/cpu/sgx/driver.h b/arch/x86/kernel/cpu/sgx/driver.h
index e4063923115b..72747d01c046 100644
--- a/arch/x86/kernel/cpu/sgx/driver.h
+++ b/arch/x86/kernel/cpu/sgx/driver.h
@@ -23,6 +23,8 @@ extern u64 sgx_attributes_reserved_mask;
extern u64 sgx_xfrm_reserved_mask;
extern u32 sgx_xsave_size_tbl[64];
+extern const struct file_operations sgx_provision_fops;
+
long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg);
int sgx_drv_init(void);
diff --git a/arch/x86/kernel/cpu/sgx/ioctl.c b/arch/x86/kernel/cpu/sgx/ioctl.c
index 51d9b24379ff..7e74efdde780 100644
--- a/arch/x86/kernel/cpu/sgx/ioctl.c
+++ b/arch/x86/kernel/cpu/sgx/ioctl.c
@@ -668,6 +668,50 @@ static long sgx_ioc_enclave_init(struct sgx_encl *encl, void __user *arg)
return ret;
}
+/**
+ * sgx_ioc_enclave_set_attribute - handler for %SGX_IOC_ENCLAVE_PROVISION
+ * @filep: open file to /dev/sgx
+ * @arg: userspace pointer to a struct sgx_enclave_provision instance
+ *
+ * Mark the enclave as being allowed to access a restricted attribute bit.
+ * The requested attribute is specified via the attribute_fd field in the
+ * provided struct sgx_enclave_provision. The attribute_fd must be a
+ * handle to an SGX attribute file, e.g. "/dev/sgx/provision".
+ *
+ * Failure to explicitly request access to a restricted attribute will cause
+ * sgx_ioc_enclave_init() to fail. Currently, the only restricted attribute
+ * is access to the PROVISION_KEY.
+ *
+ * Note, access to the EINITTOKEN_KEY is disallowed entirely.
+ *
+ * Return: 0 on success, -errno otherwise
+ */
+static long sgx_ioc_enclave_provision(struct sgx_encl *encl,
+ void __user *arg)
+{
+ struct sgx_enclave_provision params;
+ struct file *attribute_file;
+ int ret;
+
+ if (copy_from_user(¶ms, arg, sizeof(params)))
+ return -EFAULT;
+
+ attribute_file = fget(params.attribute_fd);
+ if (!attribute_file)
+ return -EINVAL;
+
+ if (attribute_file->f_op != &sgx_provision_fops) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ encl->attributes |= SGX_ATTR_PROVISIONKEY;
+ ret = 0;
+
+out:
+ fput(attribute_file);
+ return ret;
+}
long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
{
@@ -693,6 +737,9 @@ long sgx_ioctl(struct file *filep, unsigned int cmd, unsigned long arg)
case SGX_IOC_ENCLAVE_INIT:
ret = sgx_ioc_enclave_init(encl, (void __user *)arg);
break;
+ case SGX_IOC_ENCLAVE_PROVISION:
+ ret = sgx_ioc_enclave_provision(encl, (void __user *)arg);
+ break;
default:
ret = -ENOIOCTLCMD;
break;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 5/6] IMA: add hook to measure critical data from kernel components
From: Tushar Sugandhi @ 2020-09-11 17:38 UTC (permalink / raw)
To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland
Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
linux-security-module, linux-kernel, dm-devel
In-Reply-To: <6c80bdad49c72fa58b5a9fb7ce2d20c8cabe1324.camel@linux.ibm.com>
On 2020-08-31 11:23 a.m., Mimi Zohar wrote:
>> diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
>> index 52cbbc1f7ea2..a889bf40cb7e 100644
>> --- a/security/integrity/ima/ima_main.c
>> +++ b/security/integrity/ima/ima_main.c
>> @@ -869,6 +869,30 @@ void ima_kexec_cmdline(int kernel_fd, const void *buf, int size)
>> fdput(f);
>> }
>>
>> +/**
>> + * ima_measure_critical_data - measure critical data
>> + * @event_name: name for the given data
>> + * @event_data_source: name of the event data source
>> + * @buf: pointer to buffer containing data to measure
>> + * @buf_len: length of buffer(in bytes)
>> + * @measure_buf_hash: if set to true - will measure hash of the buf,
>> + * instead of buf
>> + *
>> + * Buffers can only be measured, not appraised.
>> + */
>> +int ima_measure_critical_data(const char *event_name,
>> + const char *event_data_source,
>> + const void *buf, int buf_len,
>> + bool measure_buf_hash)
>> +{
>> + if (!event_name || !event_data_source || !buf || !buf_len)
>> + return -EINVAL;
>> +
>> + return process_buffer_measurement(NULL, buf, buf_len, event_name,
>> + CRITICAL_DATA, 0, event_data_source,
>> + measure_buf_hash);
>
> This is exactly what I'm concerned about. Failure to measure data may
> be audited, but should never fail.
>
> Mimi
>
As I responded in patch 2, I can ignore the result of
process_buffer_measurement() in ima_measure_critical_data(), and make
ima_measure_critical_data() return type as "void".
But that’s the only place where the results of p_b_m() are being used.
So I might as well just revert the return type of p_b_m() to the
original "void".
>> +}
>
^ permalink raw reply
* Re: [PATCH v3 4/6] IMA: add policy to measure critical data from kernel components
From: Tushar Sugandhi @ 2020-09-11 17:29 UTC (permalink / raw)
To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland
Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
linux-security-module, linux-kernel, dm-devel
In-Reply-To: <652406e1a08d855a5d9a3e3815835653a12df411.camel@linux.ibm.com>
On 2020-08-31 11:15 a.m., Mimi Zohar wrote:
> On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
>> There would be several candidate kernel components suitable for IMA
>> measurement. Not all of them would have support for IMA measurement.
>> Also, system administrators may not want to measure data for all of
>> them, even when they support IMA measurement. An IMA policy specific
>> to various kernel components is needed to measure their respective
>> critical data.
>
> The base policy rules are wide, but may be constrained by specifying
> different options. For example the builtin policy rules cannot be
> written in terms LSM labels, which would constrain them. A policy rule
> may measure all keyrings or may constrain which keyrings need to be
> measured. Measuring critical data is not any different.
>
> Please rewrite the above paragraph accordingly.
>
Ok. Will do.
>>
>> Add a new IMA policy "critical_kernel_data_sources" to support measuring
>> various critical kernel components. This policy would enable the
>> system administrators to limit the measurement to the components,
>> if the components support IMA measurement.
>
> "critical_kernel_data_sources" is really wordy. Find a better, self
> defining term for describing the type of data, one that isn't so wordy,
> and reflect it in the code.
>
Will do. I will go with "critical_data". You also have suggested it in
the comment below.
"critical_data_sources" also seems right, but that's more wordy than
"critical_data".
Some more options we considered, but they don’t sound right.
Please let us know what do you think.
1. "critical_data_sources="
2. "critical_kernel_components=" -or- "crit_krnl_comps="
3. "critical_data_providers="
4. "critical_kernel_data_providers=" -or- "crit_krnl_dt_provs="
5. "critical_kernel_data_sources=" -or- "crit_krnl_dt_srcs="
6. "security_critical_data="
7. "protectable_data="
8. "protected_data="
9. "vital_protected_data="
>>
>> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
>> ---
>> Documentation/ABI/testing/ima_policy | 3 +++
>> security/integrity/ima/ima_policy.c | 29 +++++++++++++++++++++++++++-
>> 2 files changed, 31 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
>> index cd572912c593..7ccdc1964e29 100644
>> --- a/Documentation/ABI/testing/ima_policy
>> +++ b/Documentation/ABI/testing/ima_policy
>> @@ -48,6 +48,9 @@ Description:
>> template:= name of a defined IMA template type
>> (eg, ima-ng). Only valid when action is "measure".
>> pcr:= decimal value
>> + critical_kernel_data_sources:= list of kernel
>> + components (eg, selinux|apparmor|dm-crypt) that
>> + contain data critical to the security of the kernel.
>
> This original policy definition, for the most part, is in Backus–Naur
> format. The keyring names is an exception, because it is not limited
> to pre-defined kernel objects. The critical data hook is measuring
> things in kernel memory. As new calls to measure critical data are
> added, new identifiers would be added here.
>
> For example, if SELinux is the first example of measuring critical
> data, then the SELinux critical data patch would include
> "critical_data:= [selinux]". Each subsequent critical data being
> measured would extend this list. At the same time, the list of known
> "critical data" defined in patch 6/6 would be updated.
>
> Normally a new feature and the first usage of that feature are included
> in the same patch set. Separating them like this makes it difficult to
> write, review and upstream.
>
> Mimi
>
I agree. But the unique issue we are facing here is there are two
"first users" of this new "base series".
One, SeLinux work (driven by Lakshmi); and two, device-mapper/dm-crypt
work (driven by me).
Both of them need to be reviewed by different maintainers, may go
through several iterations before getting accepted.
That’s why we wanted to keep this "base series" independent of the
"first users"; and called the "base series" as a dependency in the
dm-crypt[1] / SeLinux[2] series.
We would appreciate your guidance on how we can better author these
three series - 1.this base series 2. dm-crypt series and 3. SeLinux
series.
[1]dm-crypt Series: https://patchwork.kernel.org/patch/11743715/
[2]SeLinux Series: https://patchwork.kernel.org/patch/11762287/
^ permalink raw reply
* Re: [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine
From: Lenny Szubowicz @ 2020-09-11 17:18 UTC (permalink / raw)
To: Mimi Zohar, Ard Biesheuvel
Cc: Linux Kernel Mailing List, linux-efi, platform-driver-x86,
linux-security-module, andy.shevchenko, James Morris, serge,
Kees Cook, Borislav Petkov, Peter Jones, David Howells, prarit
In-Reply-To: <cb8b4ebaa35d79eba65b011d042d20a991adf540.camel@linux.ibm.com>
On 9/11/20 11:59 AM, Mimi Zohar wrote:
> On Fri, 2020-09-11 at 11:54 -0400, Lenny Szubowicz wrote:
>> On 9/11/20 11:02 AM, Ard Biesheuvel wrote:
>>> On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz <lszubowi@redhat.com> wrote:
>>>>
>>>> Move the loading of certs from the UEFI MokListRT into a separate
>>>> routine to facilitate additional MokList functionality.
>>>>
>>>> There is no visible functional change as a result of this patch.
>>>> Although the UEFI dbx certs are now loaded before the MokList certs,
>>>> they are loaded onto different key rings. So the order of the keys
>>>> on their respective key rings is the same.
>>>>
>>>> Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
>>>
>>> Why did you drop Mimi's reviewed-by from this patch?
>>
>> It was not intentional. I was just not aware that I needed to propagate
>> Mimi Zohar's reviewed-by from V1 of the patch to V2.
>>
>> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
>>
>> V2 includes changes in that patch to incorporate suggestions from
>> Andy Shevchenko. My assumption was that the maintainer would
>> gather up the reviewed-by and add any signed-off-by as appropriate,
>> but it sounds like my assumption was incorrect. In retrospect, I
>> could see that having the maintainer dig through prior versions
>> of a patch set for prior reviewed-by tags could be burdensome.
>
> As much as possible moving code should be done without making changes,
> simpler for code review. Then as a separate patch you make changes.
> That way you could also have retained my Reviewed-by.
>
> Mimi
If you or Ard think I should, I can do a V3 with:
Patch V3 01: Unchanged from V2
Patch V3 02: Goes back to V1 of patch 02 that Mimi reviewed
Patch V3 03: New. Has Andy's cleanup suggestions separated from patch 02
Patch V3 04: This would most probably just be the V2 of patch 03 with no changes
-Lenny.
>
>>
>> Advice on the expected handling of this would be appreciated.
>
>
^ permalink raw reply
* Re: [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine
From: Ard Biesheuvel @ 2020-09-11 15:02 UTC (permalink / raw)
To: Lenny Szubowicz
Cc: Linux Kernel Mailing List, linux-efi, platform-driver-x86,
linux-security-module, andy.shevchenko, James Morris, serge,
Kees Cook, zohar, Borislav Petkov, Peter Jones, David Howells,
prarit
In-Reply-To: <20200905013107.10457-3-lszubowi@redhat.com>
On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz <lszubowi@redhat.com> wrote:
>
> Move the loading of certs from the UEFI MokListRT into a separate
> routine to facilitate additional MokList functionality.
>
> There is no visible functional change as a result of this patch.
> Although the UEFI dbx certs are now loaded before the MokList certs,
> they are loaded onto different key rings. So the order of the keys
> on their respective key rings is the same.
>
> Signed-off-by: Lenny Szubowicz <lszubowi@redhat.com>
Why did you drop Mimi's reviewed-by from this patch?
> ---
> security/integrity/platform_certs/load_uefi.c | 63 +++++++++++++------
> 1 file changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
> index 253fb9a7fc98..c1c622b4dc78 100644
> --- a/security/integrity/platform_certs/load_uefi.c
> +++ b/security/integrity/platform_certs/load_uefi.c
> @@ -66,6 +66,43 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
> }
>
> /*
> + * load_moklist_certs() - Load MokList certs
> + *
> + * Load the certs contained in the UEFI MokListRT database into the
> + * platform trusted keyring.
> + *
> + * Return: Status
> + */
> +static int __init load_moklist_certs(void)
> +{
> + efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
> + void *mok;
> + unsigned long moksize;
> + efi_status_t status;
> + int rc;
> +
> + /* Get MokListRT. It might not exist, so it isn't an error
> + * if we can't get it.
> + */
> + mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status);
> + if (mok) {
> + rc = parse_efi_signature_list("UEFI:MokListRT",
> + mok, moksize, get_handler_for_db);
> + kfree(mok);
> + if (rc)
> + pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
> + return rc;
> + }
> + if (status == EFI_NOT_FOUND)
> + pr_debug("MokListRT variable wasn't found\n");
> + else
> + pr_info("Couldn't get UEFI MokListRT\n");
> + return 0;
> +}
> +
> +/*
> + * load_uefi_certs() - Load certs from UEFI sources
> + *
> * Load the certs contained in the UEFI databases into the platform trusted
> * keyring and the UEFI blacklisted X.509 cert SHA256 hashes into the blacklist
> * keyring.
> @@ -73,17 +110,16 @@ static __init void *get_cert_list(efi_char16_t *name, efi_guid_t *guid,
> static int __init load_uefi_certs(void)
> {
> efi_guid_t secure_var = EFI_IMAGE_SECURITY_DATABASE_GUID;
> - efi_guid_t mok_var = EFI_SHIM_LOCK_GUID;
> - void *db = NULL, *dbx = NULL, *mok = NULL;
> - unsigned long dbsize = 0, dbxsize = 0, moksize = 0;
> + void *db = NULL, *dbx = NULL;
> + unsigned long dbsize = 0, dbxsize = 0;
> efi_status_t status;
> int rc = 0;
>
> if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE))
> return false;
>
> - /* Get db, MokListRT, and dbx. They might not exist, so it isn't
> - * an error if we can't get them.
> + /* Get db and dbx. They might not exist, so it isn't an error
> + * if we can't get them.
> */
> if (!uefi_check_ignore_db()) {
> db = get_cert_list(L"db", &secure_var, &dbsize, &status);
> @@ -102,20 +138,6 @@ static int __init load_uefi_certs(void)
> }
> }
>
> - mok = get_cert_list(L"MokListRT", &mok_var, &moksize, &status);
> - if (!mok) {
> - if (status == EFI_NOT_FOUND)
> - pr_debug("MokListRT variable wasn't found\n");
> - else
> - pr_info("Couldn't get UEFI MokListRT\n");
> - } else {
> - rc = parse_efi_signature_list("UEFI:MokListRT",
> - mok, moksize, get_handler_for_db);
> - if (rc)
> - pr_err("Couldn't parse MokListRT signatures: %d\n", rc);
> - kfree(mok);
> - }
> -
> dbx = get_cert_list(L"dbx", &secure_var, &dbxsize, &status);
> if (!dbx) {
> if (status == EFI_NOT_FOUND)
> @@ -131,6 +153,9 @@ static int __init load_uefi_certs(void)
> kfree(dbx);
> }
>
> + /* Load the MokListRT certs */
> + rc = load_moklist_certs();
> +
> return rc;
> }
> late_initcall(load_uefi_certs);
> --
> 2.27.0
>
^ permalink raw reply
* Re: [PATCH] security: keys: Use kvfree_sensitive in a few places
From: James Bottomley @ 2020-09-11 15:04 UTC (permalink / raw)
To: Alex Dewar
Cc: David Howells, Jarkko Sakkinen, James Morris, Serge E. Hallyn,
keyrings, linux-security-module, linux-kernel
In-Reply-To: <20200911114400.82207-1-alex.dewar90@gmail.com>
On Fri, 2020-09-11 at 12:44 +0100, Alex Dewar wrote:
> In big_key.c, there are a few places where memzero_explicit + kvfree
> is used. It is better to use kvfree_sensitive instead, which is more
> readable and also prevents the compiler from eliding the call to
> memzero_explicit. Fix this.
That last bit is untrue: the compiler can't elide memzero_explicit ...
that's why it has the explicit suffix.
The original problem was a lot of people do memset(.., 0, ..); kfree()
which the compiler can elide if it understands the memory is going out
of scope. Or the even more problematic memset(..., 0, ...) on a stack
variable before it goes out of scope.
We can argue about readability but there's no secret leak here.
James
^ permalink raw reply
* Re: [RESEND][RFC PATCH 0/6] Fork brute force attack mitigation (fbfam)
From: John Wood @ 2020-09-11 14:48 UTC (permalink / raw)
To: Kees Cook, Jann Horn
Cc: John Wood, Matthew Wilcox, Jonathan Corbet, Alexander Viro,
Ingo Molnar, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Steven Rostedt, Ben Segall, Mel Gorman,
Luis Chamberlain, Iurii Zaikin, James Morris, Serge E. Hallyn,
linux-doc, linux-kernel, linux-fsdevel, linux-security-module
In-Reply-To: <202009101656.FB68C6A@keescook>
Hi,
On Thu, Sep 10, 2020 at 04:58:29PM -0700, Kees Cook wrote:
> On Thu, Sep 10, 2020 at 01:21:01PM -0700, Kees Cook wrote:
> > From: John Wood <john.wood@gmx.com>
> >
> > The goal of this patch serie is to detect and mitigate a fork brute force
> > attack.
>
> Thanks for this RFC! I'm excited to get this problem finally handled in
> the kernel. Hopefully the feedback is useful. :)
Kees and Jann,
Thank you very much for your comments and advices. I'm a newbie in the
linux kernel development and this is my first attempt. So, I would prefer
to study all your comments before to reply since a big amount of terms
you expose are unknown to me.
In other words, a late reply to this serie comments is not a lack of
interest. Moreover, I think it would be better that I try to understand and
to implement your ideas before anything else.
My original patch serie is composed of 9 patches, so the 3 lasts are lost.
Kees: Have you removed them for some reason? Can you send them for review?
security/fbfam: Add two new prctls to enable and disable the fbfam feature
https://github.com/johwood/linux/commit/8a36399847213e7eb7b45b853568a53666bd0083
Documentation/security: Add documentation for the fbfam feature
https://github.com/johwood/linux/commit/fb46804541f5c0915f3f48acefbe6dc998815609
MAINTAINERS: Add a new entry for the fbfam feature
https://github.com/johwood/linux/commit/4303bc8935334136c6ef47b5e50b87cd2c472c1f
Is there a problem if I ask for some guidance (replying to this thread)
during the process to do my second patch series?
My goal is to learn as much as possible doing something useful for the
linux kernel.
Thanks a lot,
John Wood
> --
> Kees Cook
^ permalink raw reply
* Re: [PATCH v3 3/6] IMA: update process_buffer_measurement to measure buffer hash
From: Tushar Sugandhi @ 2020-09-11 16:44 UTC (permalink / raw)
To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland
Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
linux-security-module, linux-kernel, dm-devel
In-Reply-To: <f11dbfc1382e60c04fdd519ce5122239fa0cab8b.camel@linux.ibm.com>
On 2020-08-31 10:02 a.m., Mimi Zohar wrote:
> On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
>> process_buffer_measurement() currently only measures the input buffer.
>> When the buffer being measured is too large, it may result in bloated
>> IMA logs.
>
> The subject of this sentence refers to an individual record, while
> "bloated" refers to the measurement list. A "bloated" measurement list
> would contain too many or unnecessary records. Your concern seems to
> be with the size of the individual record, not the number of
> measurement list entries.
>
The intent behind that description was twofold. One, as you mentioned,
the individual record size being large; and two, multiple large-sized
individual records will eventually bloat the measurement list too.
It can happen in SeLinux case as we discovered. The SeLinux policy
(which can be a few MBs) can change from 'foo', to 'bar', back to 'foo'.
And the requirement from SeLinux is that 'foo' should be measured the
second time too. When 'foo' and 'bar' are large, the individual records
in the ima log will be large, which will also result in measurement list
being bloated.
But I understand your concern with the current wording. I will update
the patch description accordingly.
> Measuring the hash of the buffer data is similar to measuring the file
> data. In the case of the file data, however, the attestation server
> may rely on a white list manifest/DB or the file signature to verify
> the file data hash. For buffer measurements, how will the attestation
> server ascertain what is a valid buffer hash?
The client and the server implementation will go hand in hand. The
client/kernel would know what data is measured as-is
(e.g. KEXEC_CMDLINE), and what data has it’s hash measured
(e.g. SeLinux Policy). And the attestation server would verify data/hash
accordingly.
Just like the data being measured in other cases, the attestation server
will know what are possible values of the large buffers being measured.
It will have to maintain the hash of those buffer values.
>
> Hint: I assume, correct me if I'm wrong, the measurement list record
> template data is not meant to be verified, but used to detect if the "critical data" changed.
>
As mentioned above, the use case for this feature is in-memory loaded
SeLinux policy, which can be quite large (several MBs) – that's why this
functionality. The data is meant to be verified by the attestation server.
> Please update the patch description accordingly.
I will update the patch description to clarify all this.
>
>>
>> Introduce a boolean parameter measure_buf_hash to support measuring
>> hash of a buffer, which would be much smaller, instead of the buffer
>> itself.
>> Signed-off-by: Tushar Sugandhi <tusharsu@linux.microsoft.com>
>> ---
>
> <snip>
>
>> +++ b/security/integrity/ima/ima_main.c
>> @@ -733,17 +733,21 @@ int ima_load_data(enum kernel_load_data_id id)
>> * @func: IMA hook
>> * @pcr: pcr to extend the measurement
>> * @func_data: private data specific to @func, can be NULL.
>> + * @measure_buf_hash: if set to true - will measure hash of the buf,
>> + * instead of buf
>> *
>> * Based on policy, the buffer is measured into the ima log.
>> */
>> int process_buffer_measurement(struct inode *inode, const void *buf, int size,
>> const char *eventname, enum ima_hooks func,
>> - int pcr, const char *func_data)
>> + int pcr, const char *func_data,
>> + bool measure_buf_hash)
>> {
>> int ret = 0;
>> const char *audit_cause = "ENOMEM";
>> struct ima_template_entry *entry = NULL;
>> struct integrity_iint_cache iint = {};
>> + struct integrity_iint_cache digest_iint = {};
>> struct ima_event_data event_data = {.iint = &iint,
>> .filename = eventname,
>> .buf = buf,
>> @@ -752,7 +756,7 @@ int process_buffer_measurement(struct inode *inode, const void *buf, int size,
>> struct {
>> struct ima_digest_data hdr;
>> char digest[IMA_MAX_DIGEST_SIZE];
>> - } hash = {};
>> + } hash = {}, digest_hash = {};
>> int violation = 0;
>> int action = 0;
>> u32 secid;
>> @@ -801,6 +805,24 @@ int process_buffer_measurement(struct inode *inode, const void *buf, int size,
>> goto out;
>> }
>>
>> + if (measure_buf_hash) {
>> + digest_iint.ima_hash = &digest_hash.hdr;
>> + digest_iint.ima_hash->algo = ima_hash_algo;
>> + digest_iint.ima_hash->length = hash_digest_size[ima_hash_algo];
>> +
>> + ret = ima_calc_buffer_hash(hash.hdr.digest,
>> + iint.ima_hash->length,
>> + digest_iint.ima_hash);
>> + if (ret < 0) {
>> + audit_cause = "digest_hashing_error";
>> + goto out;
>> + }
>> +
>> + event_data.iint = &digest_iint;
>> + event_data.buf = hash.hdr.digest;
>> + event_data.buf_len = iint.ima_hash->length;
>> + }
>> +
>
> There seems to be some code and variable duplication by doing it this
> way. Copying the caluclated buffer data hash to a temporary buffer
> might eliminate it.
>
With the way ima_calc_buffer_hash() is implemented, I was convinced that
the variable duplication was needed. I didn't want to write a helper
function in order to minimize the unnecessary code churn in p_b_m().
But I will revisit this to see how I can reduce the code and variable
duplication.
Thanks for the feedback.
>> ret = ima_alloc_init_template(&event_data, &entry, template);
>> if (ret < 0) {
>> audit_cause = "alloc_entry";
^ permalink raw reply
* Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC)
From: Igor Zhbanov @ 2020-09-11 14:15 UTC (permalink / raw)
To: Matthew Wilcox, Al Viro
Cc: Mickaël Salaün, Mimi Zohar, linux-kernel, Aleksa Sarai,
Alexei Starovoitov, Andrew Morton, Andy Lutomirski, Arnd Bergmann,
Casey Schaufler, Christian Brauner, Christian Heimes,
Daniel Borkmann, Deven Bowers, Dmitry Vyukov, Eric Biggers,
Eric Chiang, Florian Weimer, James Morris, Jan Kara, Jann Horn,
Jonathan Corbet, Kees Cook, Lakshmi Ramasubramanian,
Matthew Garrett, Michael Kerrisk, Miklos Szeredi,
Philippe Trébuchet, Scott Shell, Sean Christopherson,
Shuah Khan, Steve Dower, Steve Grubb, Tetsuo Handa,
Thibaut Sautereau, Vincent Strubel, kernel-hardening, linux-api,
linux-integrity, linux-security-module, linux-fsdevel
In-Reply-To: <20200910200543.GY6583@casper.infradead.org>
On 10.09.2020 23:05, Matthew Wilcox wrote:
> On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote:
>> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote:
>>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote:
>>>> There is also the use case of noexec mounts and file permissions. From
>>>> user space point of view, it doesn't matter which kernel component is in
>>>> charge of defining the policy. The syscall should then not be tied with
>>>> a verification/integrity/signature/appraisal vocabulary, but simply an
>>>> access control one.
>>>
>>> permission()?
>>
>> int lsm(int fd, const char *how, char *error, int size);
>>
>> Seriously, this is "ask LSM to apply special policy to file"; let's
>> _not_ mess with flags, etc. for that; give it decent bandwidth
>> and since it's completely opaque for the rest of the kernel,
>> just a pass a string to be parsed by LSM as it sees fit.
>
> Hang on, it does have some things which aren't BD^W^WLSM. It lets
> the interpreter honour the mount -o noexec option. I presume it's
> not easily defeated by
> cat /home/salaun/bin/bad.pl | perl -
Hi!
It could be bypassed this way. There are several ways of executing some
script:
1) /unsigned.sh (Already handled by IMA)
2) bash /unsigned.sh (Not handled. Works even with "-o noexec" mount)
3) bash < /unsigned.sh (Not handled. Works even with "-o noexec" mount)
4) cat /unsigned.sh | bash (Not handled. Works even with "-o noexec" mount)
AFAIK, the proposed syscall solves #2 and may be #3. As for #4 in security
critical environments there should be system-wide options to disable
interpreting scripts from the standard input. I suppose, executing commands
from the stdin is a rare case, and could be avoided entirely in security
critical environments. And yes, some help from the interpreters is needed
for that.
As for the usage of the system call, I have a proposal to extend its usage
to validate systemd unit files. Because a unit file could specify what UID
to use for a service, also it contains ExecStartPre which is actually a script
and is running as root (for the system session services).
For the syscall name it could be:
- trusted_file()
- trusted_file_content()
- valid_file()
- file_integrity()
because what we are checking here is the file content integrity (IMA) and
may be file permissions/attrs integrity (EVM).
^ permalink raw reply
* Re: [PATCH V2 0/3] integrity: Load certs from EFI MOK config table
From: Ard Biesheuvel @ 2020-09-11 15:17 UTC (permalink / raw)
To: Lenny Szubowicz
Cc: Linux Kernel Mailing List, linux-efi, platform-driver-x86,
linux-security-module, andy.shevchenko, James Morris, serge,
Kees Cook, zohar, Borislav Petkov, Peter Jones, David Howells,
prarit
In-Reply-To: <20200905013107.10457-1-lszubowi@redhat.com>
On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz <lszubowi@redhat.com> wrote:
>
> Because of system-specific EFI firmware limitations, EFI volatile
> variables may not be capable of holding the required contents of
> the Machine Owner Key (MOK) certificate store when the certificate
> list grows above some size. Therefore, an EFI boot loader may pass
> the MOK certs via a EFI configuration table created specifically for
> this purpose to avoid this firmware limitation.
>
> An EFI configuration table is a simpler and more robust mechanism
> compared to EFI variables and is well suited for one-way passage
> of static information from a pre-OS environment to the kernel.
>
> Entries in the MOK variable configuration table are named key/value
> pairs. Therefore the shim boot loader can create a MokListRT named
> entry in the MOK configuration table that contains exactly the same
> data as the MokListRT UEFI variable does or would otherwise contain.
> As such, the kernel can load certs from the data in the MokListRT
> configuration table entry data in the same way that it loads certs
> from the data returned by the EFI GetVariable() runtime call for the
> MokListRT variable.
>
> This patch set does not remove the support for loading certs from the
> EFI MOK variables into the platform key ring. However, if both the EFI
> MOK configuration table and corresponding EFI MOK variables are present,
> the MOK table is used as the source of MOK certs.
>
> The contents of the individual named MOK config table entries are
> made available to user space as individual sysfs binary files,
> which are read-only to root, under:
>
> /sys/firmware/efi/mok-variables/
>
> This enables an updated mokutil to provide support for:
>
> mokutil --list-enrolled
>
> such that it can provide accurate information regardless of whether
> the MOK configuration table or MOK EFI variables were the source
> for certs. Note that all modifications of MOK related state are still
> initiated by mokutil via EFI variables.
>
> V2: Incorporate feedback from V1
> Patch 01: efi: Support for MOK variable config table
> - Minor update to change log; no code changes
> Patch 02: integrity: Move import of MokListRT certs to a separate routine
> - Clean up code flow in code moved to load_moklist_certs()
> - Remove some unnecessary initialization of variables
> Patch 03: integrity: Load certs from the EFI MOK config table
> - Update required due to changes in patch 02.
> - Remove unnecessary init of mokvar_entry in load_moklist_certs()
>
> V1:
> https://lore.kernel.org/lkml/20200826034455.28707-1-lszubowi@redhat.com/
>
> Lenny Szubowicz (3):
> efi: Support for MOK variable config table
> integrity: Move import of MokListRT certs to a separate routine
> integrity: Load certs from the EFI MOK config table
>
> arch/x86/kernel/setup.c | 1 +
> arch/x86/platform/efi/efi.c | 3 +
> drivers/firmware/efi/Makefile | 1 +
> drivers/firmware/efi/arm-init.c | 1 +
> drivers/firmware/efi/efi.c | 6 +
> drivers/firmware/efi/mokvar-table.c | 360 ++++++++++++++++++
> include/linux/efi.h | 34 ++
> security/integrity/platform_certs/load_uefi.c | 85 ++++-
> 8 files changed, 472 insertions(+), 19 deletions(-)
> create mode 100644 drivers/firmware/efi/mokvar-table.c
>
Thanks. I have tentatively queued these up in efi/next.
Mimi, please let me know if you have any thoughts on 3/3, and whether
your R-b on 2/3 [v1] implies that you are ok with the series going
through the EFI tree.
--
Ard.
^ permalink raw reply
* Re: [PATCH v3 2/6] IMA: change process_buffer_measurement return type from void to int
From: Tushar Sugandhi @ 2020-09-11 16:22 UTC (permalink / raw)
To: Mimi Zohar, stephen.smalley.work, casey, agk, snitzer, gmazyland
Cc: tyhicks, sashal, jmorris, nramas, linux-integrity, selinux,
linux-security-module, linux-kernel, dm-devel
In-Reply-To: <e76bdb18c6045702156441470e50380445e6e218.camel@linux.ibm.com>
On 2020-08-31 4:36 a.m., Mimi Zohar wrote:
> On Thu, 2020-08-27 at 18:57 -0700, Tushar Sugandhi wrote:
>> process_buffer_measurement() does not return the result of the operation.
>> Therefore, the consumers of this function cannot act on it, if needed.
>>
>> Update return type of process_buffer_measurement() from void to int.
>
> Failure to measure may be audited, but should never fail. This is one
> of the main differences between secure and trusted boot concepts.
> Notice in process_measurement() that -EACCES is only returned for
> appraisal.
>
> Returning a failure from process_buffer_measurement() in itself isn't a
> problem, as long as the failure isn't returned to the LSM/IMA hook.
> However, just as the callers of process_measurement() originally
> processed the result, that processing was moved into
> process_measurement() [1].
>
> Mimi
>
> [1] 750943a30714 ima: remove enforce checking duplication
>
I can ignore the result of process_buffer_measurement() in
ima_measure_critical_data(), and make ima_measure_critical_data()
return type "void".
But currently ima_measure_critical_data() is the only place where the
results of p_b_m() are being used.
So I might as well just revert back the return type of p_b_m() to
the original "void".
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox