All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	James Morris <jmorris@namei.org>,
	"Serge E . Hallyn" <serge@hallyn.com>,
	Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	Prakhar Srivastava <prsriva02@gmail.com>,
	linux-kernel@vger.kernel.org, linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	kexec@lists.infradead.org
Subject: Re: [PATCH 12/12] ima: Support additional conditionals in the KEXEC_CMDLINE hook function
Date: Thu, 25 Jun 2020 17:59:57 -0500	[thread overview]
Message-ID: <20200625225957.GC4694@sequoia> (raw)
In-Reply-To: <1593125804.27152.426.camel@linux.ibm.com>

On 2020-06-25 18:56:44, Mimi Zohar wrote:
> On Mon, 2020-06-22 at 19:32 -0500, Tyler Hicks wrote:
> > Take the properties of the kexec kernel's inode and the current task
> > ownership into consideration when matching a KEXEC_CMDLINE operation to
> > the rules in the IMA policy. This allows for some uniformity when
> > writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK,
> > and KEXEC_CMDLINE operations.
> > 
> > Prior to this patch, it was not possible to write a set of rules like
> > this:
> > 
> >  dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> >  measure func=KEXEC_KERNEL_CHECK
> >  measure func=KEXEC_INITRAMFS_CHECK
> >  measure func=KEXEC_CMDLINE
> > 
> > The inode information associated with the kernel being loaded by a
> > kexec_kernel_load(2) syscall can now be included in the decision to
> > measure or not
> > 
> > Additonally, the uid, euid, and subj_* conditionals can also now be
> > used in KEXEC_CMDLINE rules. There was no technical reason as to why
> > those conditionals weren't being considered previously other than
> > ima_match_rules() didn't have a valid inode to use so it immediately
> > bailed out for KEXEC_CMDLINE operations rather than going through the
> > full list of conditional comparisons.
> 
> This makes a lot of sense.
> 
> <snip>
>  
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index c1583d98c5e5..82acd66bf653 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -731,13 +731,15 @@ int ima_load_data(enum kernel_load_data_id id)
> >   * @eventname: event name to be used for the buffer entry.
> >   * @func: IMA hook
> >   * @pcr: pcr to extend the measurement
> > + * @inode: inode associated with the object being measured (NULL for KEY_CHECK)
> >   * @keyring: keyring name to determine the action to be performed
> >   *
> >   * Based on policy, the buffer is measured into the ima log.
> >   */
> >  void process_buffer_measurement(const void *buf, int size,
> >  				const char *eventname, enum ima_hooks func,
> > -				int pcr, const char *keyring)
> > +				int pcr, struct inode *inode,
> > +				const char *keyring)
> >  {
> 
> The file descriptor is passed as the first arg to
> process_measurement().  Sorry for the patch churn, but could we do the
> same for process_buffer_measurements.  As much as possible lets keep
> them in same.

Yep! That makes sense to me.

Tyler

> 
> thanks,
> 
> Mimi

WARNING: multiple messages have this Message-ID (diff)
From: Tyler Hicks <tyhicks@linux.microsoft.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	Prakhar Srivastava <prsriva02@gmail.com>,
	kexec@lists.infradead.org, James Morris <jmorris@namei.org>,
	linux-kernel@vger.kernel.org,
	Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	linux-security-module@vger.kernel.org,
	Eric Biederman <ebiederm@xmission.com>,
	linux-integrity@vger.kernel.org,
	"Serge E . Hallyn" <serge@hallyn.com>
Subject: Re: [PATCH 12/12] ima: Support additional conditionals in the KEXEC_CMDLINE hook function
Date: Thu, 25 Jun 2020 17:59:57 -0500	[thread overview]
Message-ID: <20200625225957.GC4694@sequoia> (raw)
In-Reply-To: <1593125804.27152.426.camel@linux.ibm.com>

On 2020-06-25 18:56:44, Mimi Zohar wrote:
> On Mon, 2020-06-22 at 19:32 -0500, Tyler Hicks wrote:
> > Take the properties of the kexec kernel's inode and the current task
> > ownership into consideration when matching a KEXEC_CMDLINE operation to
> > the rules in the IMA policy. This allows for some uniformity when
> > writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK,
> > and KEXEC_CMDLINE operations.
> > 
> > Prior to this patch, it was not possible to write a set of rules like
> > this:
> > 
> >  dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
> >  dont_measure func=KEXEC_CMDLINE obj_type=foo_t
> >  measure func=KEXEC_KERNEL_CHECK
> >  measure func=KEXEC_INITRAMFS_CHECK
> >  measure func=KEXEC_CMDLINE
> > 
> > The inode information associated with the kernel being loaded by a
> > kexec_kernel_load(2) syscall can now be included in the decision to
> > measure or not
> > 
> > Additonally, the uid, euid, and subj_* conditionals can also now be
> > used in KEXEC_CMDLINE rules. There was no technical reason as to why
> > those conditionals weren't being considered previously other than
> > ima_match_rules() didn't have a valid inode to use so it immediately
> > bailed out for KEXEC_CMDLINE operations rather than going through the
> > full list of conditional comparisons.
> 
> This makes a lot of sense.
> 
> <snip>
>  
> > diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c
> > index c1583d98c5e5..82acd66bf653 100644
> > --- a/security/integrity/ima/ima_main.c
> > +++ b/security/integrity/ima/ima_main.c
> > @@ -731,13 +731,15 @@ int ima_load_data(enum kernel_load_data_id id)
> >   * @eventname: event name to be used for the buffer entry.
> >   * @func: IMA hook
> >   * @pcr: pcr to extend the measurement
> > + * @inode: inode associated with the object being measured (NULL for KEY_CHECK)
> >   * @keyring: keyring name to determine the action to be performed
> >   *
> >   * Based on policy, the buffer is measured into the ima log.
> >   */
> >  void process_buffer_measurement(const void *buf, int size,
> >  				const char *eventname, enum ima_hooks func,
> > -				int pcr, const char *keyring)
> > +				int pcr, struct inode *inode,
> > +				const char *keyring)
> >  {
> 
> The file descriptor is passed as the first arg to
> process_measurement().  Sorry for the patch churn, but could we do the
> same for process_buffer_measurements.  As much as possible lets keep
> them in same.

Yep! That makes sense to me.

Tyler

> 
> thanks,
> 
> Mimi

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2020-06-25 23:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-23  0:32 [PATCH 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support Tyler Hicks
2020-06-23  0:32 ` Tyler Hicks
2020-06-23  0:32 ` [PATCH 01/12] ima: Have the LSM free its audit rule Tyler Hicks
2020-06-23  0:55   ` Casey Schaufler
2020-06-23  3:04     ` Tyler Hicks
2020-06-23 23:04   ` Tyler Hicks
2020-06-25 19:41   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 02/12] ima: Create a function to free a rule entry Tyler Hicks
2020-06-25 19:33   ` Mimi Zohar
2020-06-25 19:56     ` Tyler Hicks
2020-06-25 20:32       ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 03/12] ima: Free the entire rule when deleting a list of rules Tyler Hicks
2020-06-25 21:05   ` Mimi Zohar
2020-06-25 21:07   ` Mimi Zohar
2020-06-25 21:08     ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 04/12] ima: Free the entire rule if it fails to parse Tyler Hicks
2020-06-23  0:32 ` [PATCH 05/12] ima: Fail rule parsing when buffer hook functions have an invalid action Tyler Hicks
2020-06-25 21:51   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 06/12] ima: Fail rule parsing when the KEXEC_CMDLINE hook is combined with an invalid cond Tyler Hicks
2020-06-25 21:53   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 07/12] ima: Fail rule parsing when the KEY_CHECK " Tyler Hicks
2020-06-23  0:32 ` [PATCH 08/12] ima: Shallow copy the args_p member of ima_rule_entry.lsm elements Tyler Hicks
2020-06-25 21:18   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 09/12] ima: Use correct type for " Tyler Hicks
2020-06-25 21:20   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 10/12] ima: Move validation of the keyrings conditional into ima_validate_rule() Tyler Hicks
2020-06-25 19:50   ` Tyler Hicks
2020-06-25 20:46     ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 11/12] ima: Use the common function to detect LSM conditionals in a rule Tyler Hicks
2020-06-25 22:45   ` Mimi Zohar
2020-06-23  0:32 ` [PATCH 12/12] ima: Support additional conditionals in the KEXEC_CMDLINE hook function Tyler Hicks
2020-06-23  0:32   ` Tyler Hicks
2020-06-25 22:56   ` Mimi Zohar
2020-06-25 22:56     ` Mimi Zohar
2020-06-25 22:59     ` Tyler Hicks [this message]
2020-06-25 22:59       ` Tyler Hicks

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=20200625225957.GC4694@sequoia \
    --to=tyhicks@linux.microsoft.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=jmorris@namei.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=prsriva02@gmail.com \
    --cc=serge@hallyn.com \
    --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.