All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruno Meneguele <bmeneg@redhat.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
	linux-integrity@vger.kernel.org, erichte@linux.ibm.com,
	nayna@linux.ibm.com, stable@vger.kernel.org
Subject: Re: [PATCH v5] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime
Date: Mon, 13 Jul 2020 12:03:51 -0300	[thread overview]
Message-ID: <20200713150351.GC4730@glitch> (raw)
In-Reply-To: <20200710192516.GC10547@glitch>

[-- Attachment #1: Type: text/plain, Size: 5872 bytes --]

On Fri, Jul 10, 2020 at 04:25:16PM -0300, Bruno Meneguele wrote:
> On Fri, Jul 10, 2020 at 02:54:48PM -0400, Mimi Zohar wrote:
> > On Fri, 2020-07-10 at 15:34 -0300, Bruno Meneguele wrote:
> > > On Fri, Jul 10, 2020 at 03:03:38PM -0300, Bruno Meneguele wrote:
> > > > On Fri, Jul 10, 2020 at 01:23:24PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2020-07-09 at 13:46 -0300, Bruno Meneguele wrote:
> > > > > > APPRAISE_BOOTPARAM has been marked as dependent on !ARCH_POLICY in compile
> > > > > > time, enforcing the appraisal whenever the kernel had the arch policy option
> > > > > > enabled.
> > > > > 
> > > > > > However it breaks systems where the option is set but the system didn't
> > > > > > boot in a "secure boot" platform. In this scenario, anytime an appraisal
> > > > > > policy (i.e. ima_policy=appraisal_tcb) is used it will be forced, without
> > > > > > giving the user the opportunity to label the filesystem, before enforcing
> > > > > > integrity.
> > > > > > 
> > > > > > Considering the ARCH_POLICY is only effective when secure boot is actually
> > > > > > enabled this patch remove the compile time dependency and move it to a
> > > > > > runtime decision, based on the secure boot state of that platform.
> > > > > 
> > > > > Perhaps we could simplify this patch description a bit?
> > > > > 
> > > > > The IMA_APPRAISE_BOOTPARAM config allows enabling different
> > > > > "ima_appraise=" modes - log, fix, enforce - at run time, but not when
> > > > > IMA architecture specific policies are enabled.  This prevents
> > > > > properly labeling the filesystem on systems where secure boot is
> > > > > supported, but not enabled on the platform.  Only when secure boot is
> > > > > enabled, should these IMA appraise modes be disabled.
> > > > > 
> > > > > This patch removes the compile time dependency and makes it a runtime
> > > > > decision, based on the secure boot state of that platform.
> > > > > 
> > > > 
> > > > Sounds good to me.
> > > > 
> > > > > <snip>
> > > > > 
> > > > > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> > > > > > index a9649b04b9f1..884de471b38a 100644
> > > > > > --- a/security/integrity/ima/ima_appraise.c
> > > > > > +++ b/security/integrity/ima/ima_appraise.c
> > > > > > @@ -19,6 +19,11 @@
> > > > > >  static int __init default_appraise_setup(c
> > > > > 
> > > > > > har *str)
> > > > > >  {
> > > > > >  #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
> > > > > > +	if (arch_ima_get_secureboot()) {
> > > > > > +		pr_info("appraise boot param ignored: secure boot enabled");
> > > > > 
> > > > > Instead of a generic statement, is it possible to include the actual
> > > > > option being denied?  Perhaps something like: "Secure boot enabled,
> > > > > ignoring %s boot command line option"
> > > > > 
> > > > > Mimi
> > > > > 
> > > > 
> > > > Yes, sure.
> > > > 
> > > 
> > > Btw, would it make sense to first make sure we have a valid "str"
> > > option and not something random to print?
> > >  
> > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> > > index a9649b04b9f1..1f1175531d3e 100644
> > > --- a/security/integrity/ima/ima_appraise.c
> > > +++ b/security/integrity/ima/ima_appraise.c
> > > @@ -25,6 +25,16 @@ static int __init default_appraise_setup(char *str)
> > >                 ima_appraise = IMA_APPRAISE_LOG;
> > >         else if (strncmp(str, "fix", 3) == 0)
> > >                 ima_appraise = IMA_APPRAISE_FIX;
> > > +       else
> > > +               pr_info("invalid \"%s\" appraise option");
> > > +
> > > +       if (arch_ima_get_secureboot()) {
> > > +               if (!is_ima_appraise_enabled()) {
> > > +                       pr_info("Secure boot enabled: ignoring ima_appraise=%s boot parameter option",
> > > +                               str);
> > > +                       ima_appraise = IMA_APPRAISE_ENFORCE;
> > > +               }
> > > +       }
> > 
> > Providing feedback is probably a good idea.  However, the
> > "arch_ima_get_secureboot" test can't come after setting
> > "ima_appraise."
> > 
> 
> Sorry, but I'm not sure if I got the reason to why it can't be done
> after: would it be basically to prevent any further processing about
> ima_appraise as a matter of security principle? Or maybe to keep the
> dependency between secureboot and bootparam truly strict? 
> 
> Or are there something else I'm missing?
> 

I'm going to send a v6 with the pr_info() placed in the beginning
directly printing 'str', thus we can have the actual issue solved. 

Then later I send another patches to handle the other cases of limiting
'str' printing and also giving the user a feedback about invalid
ima_appraise= options. So we can discuss further on that.

Thanks Mimi.

> > Mimi
> > 
> > >  #endif
> > >         return 1;
> > >  }
> > > 
> > > 
> > > The "else" there I think would make sense as well, at least to give the
> > > user some feedback about a possible mispelling of him (as a separate
> > > patch).
> > > 
> > > And "if(!is_ima_appraise_enabled())" would avoid to print anything about
> > > "ignoring the option" to the user in case he explicitly set "enforce",
> > > which we know there isn't any real effect but is allowed and shown in
> > > kernel-parameters.txt.
> > > 
> > > > Thanks!
> > > > 
> > > > > > +		return 1;
> > > > > > +	}
> > > > > > +
> > > > > >  	if (strncmp(str, "off", 3) == 0)
> > > > > >  		ima_appraise = 0;
> > > > > >  	else if (strncmp(str, "log", 3) == 0)
> > > > > 
> > > > 
> > > > -- 
> > > > bmeneg 
> > > > PGP Key: http://bmeneg.com/pubkey.txt
> > > 
> > > 
> > > 
> > 
> 
> -- 
> bmeneg 
> PGP Key: http://bmeneg.com/pubkey.txt



-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Bruno Meneguele <bmeneg@redhat.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: linux-s390@vger.kernel.org, nayna@linux.ibm.com,
	erichte@linux.ibm.com, x86@kernel.org,
	linux-kernel@vger.kernel.org, stable@vger.kernel.org,
	linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v5] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime
Date: Mon, 13 Jul 2020 12:03:51 -0300	[thread overview]
Message-ID: <20200713150351.GC4730@glitch> (raw)
In-Reply-To: <20200710192516.GC10547@glitch>

[-- Attachment #1: Type: text/plain, Size: 5872 bytes --]

On Fri, Jul 10, 2020 at 04:25:16PM -0300, Bruno Meneguele wrote:
> On Fri, Jul 10, 2020 at 02:54:48PM -0400, Mimi Zohar wrote:
> > On Fri, 2020-07-10 at 15:34 -0300, Bruno Meneguele wrote:
> > > On Fri, Jul 10, 2020 at 03:03:38PM -0300, Bruno Meneguele wrote:
> > > > On Fri, Jul 10, 2020 at 01:23:24PM -0400, Mimi Zohar wrote:
> > > > > On Thu, 2020-07-09 at 13:46 -0300, Bruno Meneguele wrote:
> > > > > > APPRAISE_BOOTPARAM has been marked as dependent on !ARCH_POLICY in compile
> > > > > > time, enforcing the appraisal whenever the kernel had the arch policy option
> > > > > > enabled.
> > > > > 
> > > > > > However it breaks systems where the option is set but the system didn't
> > > > > > boot in a "secure boot" platform. In this scenario, anytime an appraisal
> > > > > > policy (i.e. ima_policy=appraisal_tcb) is used it will be forced, without
> > > > > > giving the user the opportunity to label the filesystem, before enforcing
> > > > > > integrity.
> > > > > > 
> > > > > > Considering the ARCH_POLICY is only effective when secure boot is actually
> > > > > > enabled this patch remove the compile time dependency and move it to a
> > > > > > runtime decision, based on the secure boot state of that platform.
> > > > > 
> > > > > Perhaps we could simplify this patch description a bit?
> > > > > 
> > > > > The IMA_APPRAISE_BOOTPARAM config allows enabling different
> > > > > "ima_appraise=" modes - log, fix, enforce - at run time, but not when
> > > > > IMA architecture specific policies are enabled.  This prevents
> > > > > properly labeling the filesystem on systems where secure boot is
> > > > > supported, but not enabled on the platform.  Only when secure boot is
> > > > > enabled, should these IMA appraise modes be disabled.
> > > > > 
> > > > > This patch removes the compile time dependency and makes it a runtime
> > > > > decision, based on the secure boot state of that platform.
> > > > > 
> > > > 
> > > > Sounds good to me.
> > > > 
> > > > > <snip>
> > > > > 
> > > > > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> > > > > > index a9649b04b9f1..884de471b38a 100644
> > > > > > --- a/security/integrity/ima/ima_appraise.c
> > > > > > +++ b/security/integrity/ima/ima_appraise.c
> > > > > > @@ -19,6 +19,11 @@
> > > > > >  static int __init default_appraise_setup(c
> > > > > 
> > > > > > har *str)
> > > > > >  {
> > > > > >  #ifdef CONFIG_IMA_APPRAISE_BOOTPARAM
> > > > > > +	if (arch_ima_get_secureboot()) {
> > > > > > +		pr_info("appraise boot param ignored: secure boot enabled");
> > > > > 
> > > > > Instead of a generic statement, is it possible to include the actual
> > > > > option being denied?  Perhaps something like: "Secure boot enabled,
> > > > > ignoring %s boot command line option"
> > > > > 
> > > > > Mimi
> > > > > 
> > > > 
> > > > Yes, sure.
> > > > 
> > > 
> > > Btw, would it make sense to first make sure we have a valid "str"
> > > option and not something random to print?
> > >  
> > > diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c
> > > index a9649b04b9f1..1f1175531d3e 100644
> > > --- a/security/integrity/ima/ima_appraise.c
> > > +++ b/security/integrity/ima/ima_appraise.c
> > > @@ -25,6 +25,16 @@ static int __init default_appraise_setup(char *str)
> > >                 ima_appraise = IMA_APPRAISE_LOG;
> > >         else if (strncmp(str, "fix", 3) == 0)
> > >                 ima_appraise = IMA_APPRAISE_FIX;
> > > +       else
> > > +               pr_info("invalid \"%s\" appraise option");
> > > +
> > > +       if (arch_ima_get_secureboot()) {
> > > +               if (!is_ima_appraise_enabled()) {
> > > +                       pr_info("Secure boot enabled: ignoring ima_appraise=%s boot parameter option",
> > > +                               str);
> > > +                       ima_appraise = IMA_APPRAISE_ENFORCE;
> > > +               }
> > > +       }
> > 
> > Providing feedback is probably a good idea.  However, the
> > "arch_ima_get_secureboot" test can't come after setting
> > "ima_appraise."
> > 
> 
> Sorry, but I'm not sure if I got the reason to why it can't be done
> after: would it be basically to prevent any further processing about
> ima_appraise as a matter of security principle? Or maybe to keep the
> dependency between secureboot and bootparam truly strict? 
> 
> Or are there something else I'm missing?
> 

I'm going to send a v6 with the pr_info() placed in the beginning
directly printing 'str', thus we can have the actual issue solved. 

Then later I send another patches to handle the other cases of limiting
'str' printing and also giving the user a feedback about invalid
ima_appraise= options. So we can discuss further on that.

Thanks Mimi.

> > Mimi
> > 
> > >  #endif
> > >         return 1;
> > >  }
> > > 
> > > 
> > > The "else" there I think would make sense as well, at least to give the
> > > user some feedback about a possible mispelling of him (as a separate
> > > patch).
> > > 
> > > And "if(!is_ima_appraise_enabled())" would avoid to print anything about
> > > "ignoring the option" to the user in case he explicitly set "enforce",
> > > which we know there isn't any real effect but is allowed and shown in
> > > kernel-parameters.txt.
> > > 
> > > > Thanks!
> > > > 
> > > > > > +		return 1;
> > > > > > +	}
> > > > > > +
> > > > > >  	if (strncmp(str, "off", 3) == 0)
> > > > > >  		ima_appraise = 0;
> > > > > >  	else if (strncmp(str, "log", 3) == 0)
> > > > > 
> > > > 
> > > > -- 
> > > > bmeneg 
> > > > PGP Key: http://bmeneg.com/pubkey.txt
> > > 
> > > 
> > > 
> > 
> 
> -- 
> bmeneg 
> PGP Key: http://bmeneg.com/pubkey.txt



-- 
bmeneg 
PGP Key: http://bmeneg.com/pubkey.txt

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-07-13 15:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-09 16:46 [PATCH v5] ima: move APPRAISE_BOOTPARAM dependency on ARCH_POLICY to runtime Bruno Meneguele
2020-07-09 16:46 ` Bruno Meneguele
2020-07-10 17:23 ` Mimi Zohar
2020-07-10 18:03   ` Bruno Meneguele
2020-07-10 18:03     ` Bruno Meneguele
2020-07-10 18:34     ` Bruno Meneguele
2020-07-10 18:34       ` Bruno Meneguele
2020-07-10 18:54       ` Mimi Zohar
2020-07-10 18:54         ` Mimi Zohar
2020-07-10 19:25         ` Bruno Meneguele
2020-07-10 19:25           ` Bruno Meneguele
2020-07-13 15:03           ` Bruno Meneguele [this message]
2020-07-13 15:03             ` Bruno Meneguele

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200713150351.GC4730@glitch \
    --to=bmeneg@redhat.com \
    --cc=erichte@linux.ibm.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nayna@linux.ibm.com \
    --cc=stable@vger.kernel.org \
    --cc=x86@kernel.org \
    --cc=zohar@linux.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.