All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Kees Cook <keescook@chromium.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	kexec@lists.infradead.org, linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	Andres Rodriguez <andresx7@gmail.com>,
	linux-integrity@vger.kernel.org,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper
Date: Fri, 18 May 2018 11:29:36 -0400	[thread overview]
Message-ID: <1526657376.3404.15.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <cb7f7401-ce7e-f4b5-2daa-62eaa78492ca@schaufler-ca.com>

On Fri, 2018-05-18 at 07:58 -0700, Casey Schaufler wrote:
> On 5/18/2018 4:30 AM, Mimi Zohar wrote:

> > Having to define a separate LSM hook for each of the original, non
> > kernel_read_file(), buffer based method callers, kind of makes sense,
> > as the callers themselves are specific, but is it really necessary?
> > Could we define a new, generic LSM hook named
> > security_kernel_buffer_data() for this purpose?
> 
> If there are two disparate behaviors wrapped into kernel_read_file()
> Eric (bless him) is right. It should be broken into two hooks. I think
> that if we look (too) carefully we'll find other places where hooks
> should get broken up, or combined*. My question is just how important
> is it that this gets changed?

Other than the LSM call in copy_module_from_user(), this patch set is
adding the LSM call in kexec_load() and firmware_fallback_sysfs().

Eric, the question remains whether we need distinct LSM hooks in each
of these places or can we have a single, generic LSM hook named
security_kernel_buffer_data()?

Mimi


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

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: Casey Schaufler <casey@schaufler-ca.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-kernel@vger.kernel.org, David Howells <dhowells@redhat.com>,
	"Luis R . Rodriguez" <mcgrof@kernel.org>,
	kexec@lists.infradead.org, Andres Rodriguez <andresx7@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Kees Cook <keescook@chromium.org>,
	Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper
Date: Fri, 18 May 2018 11:29:36 -0400	[thread overview]
Message-ID: <1526657376.3404.15.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <cb7f7401-ce7e-f4b5-2daa-62eaa78492ca@schaufler-ca.com>

On Fri, 2018-05-18 at 07:58 -0700, Casey Schaufler wrote:
> On 5/18/2018 4:30 AM, Mimi Zohar wrote:

> > Having to define a separate LSM hook for each of the original, non
> > kernel_read_file(), buffer based method callers, kind of makes sense,
> > as the callers themselves are specific, but is it really necessary?
> > Could we define a new, generic LSM hook named
> > security_kernel_buffer_data() for this purpose?
> 
> If there are two disparate behaviors wrapped into kernel_read_file()
> Eric (bless him) is right. It should be broken into two hooks. I think
> that if we look (too) carefully we'll find other places where hooks
> should get broken up, or combined*. My question is just how important
> is it that this gets changed?

Other than the LSM call in copy_module_from_user(), this patch set is
adding the LSM call in kexec_load() and firmware_fallback_sysfs().

Eric, the question remains whether we need distinct LSM hooks in each
of these places or can we have a single, generic LSM hook named
security_kernel_buffer_data()?

Mimi

WARNING: multiple messages have this Message-ID (diff)
From: zohar@linux.vnet.ibm.com (Mimi Zohar)
To: linux-security-module@vger.kernel.org
Subject: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper
Date: Fri, 18 May 2018 11:29:36 -0400	[thread overview]
Message-ID: <1526657376.3404.15.camel@linux.vnet.ibm.com> (raw)
In-Reply-To: <cb7f7401-ce7e-f4b5-2daa-62eaa78492ca@schaufler-ca.com>

On Fri, 2018-05-18 at 07:58 -0700, Casey Schaufler wrote:
> On 5/18/2018 4:30 AM, Mimi Zohar wrote:

> > Having to define a separate LSM hook for each of the original, non
> > kernel_read_file(), buffer based method callers, kind of makes sense,
> > as the callers themselves are specific, but is it really necessary?
> > Could we define a new, generic LSM hook named
> > security_kernel_buffer_data() for this purpose?
> 
> If there are two disparate behaviors wrapped into kernel_read_file()
> Eric (bless him) is right. It should be broken into two hooks. I think
> that if we look (too) carefully we'll find other places where hooks
> should get broken up, or combined*. My question is just how important
> is it that this gets changed?

Other than the LSM call in copy_module_from_user(), this patch set is
adding the LSM call in kexec_load() and firmware_fallback_sysfs().

Eric, the question remains whether we need distinct LSM hooks in each
of these places or can we have a single, generic LSM hook named
security_kernel_buffer_data()?

Mimi

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2018-05-18 15:30 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 14:48 [PATCH v2 0/9] kexec/firmware: support system wide policy requiring signatures Mimi Zohar
2018-05-17 14:48 ` Mimi Zohar
2018-05-17 14:48 ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 1/9] ima: based on policy verify firmware signatures (pre-allocated buffer) Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 2/9] ima: fix updating the ima_appraise flag Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-18  0:24   ` Casey Schaufler
2018-05-18  0:24     ` Casey Schaufler
2018-05-18  0:24     ` Casey Schaufler
2018-05-18  3:37     ` Eric W. Biederman
2018-05-18  3:37       ` Eric W. Biederman
2018-05-18  3:37       ` Eric W. Biederman
2018-05-18 11:30       ` Mimi Zohar
2018-05-18 11:30         ` Mimi Zohar
2018-05-18 11:30         ` Mimi Zohar
2018-05-18 11:30         ` Mimi Zohar
2018-05-18 14:58         ` Casey Schaufler
2018-05-18 14:58           ` Casey Schaufler
2018-05-18 14:58           ` Casey Schaufler
2018-05-18 14:58           ` Casey Schaufler
2018-05-18 15:29           ` Mimi Zohar [this message]
2018-05-18 15:29             ` Mimi Zohar
2018-05-18 15:29             ` Mimi Zohar
2018-05-18 17:13       ` James Morris
2018-05-18 17:13         ` James Morris
2018-05-18 17:13         ` James Morris
2018-05-18 17:55         ` Mimi Zohar
2018-05-18 17:55           ` Mimi Zohar
2018-05-18 17:55           ` Mimi Zohar
2018-05-18 17:55           ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 4/9] kexec: add call to LSM hook in original kexec_load syscall Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 5/9] ima: based on policy require signed kexec kernel images Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 6/9] firmware: add call to LSM hook before firmware sysfs fallback Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 7/9] ima: based on policy require signed firmware (sysfs fallback) Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 8/9] ima: add build time policy Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48 ` [PATCH v2 9/9] ima: based on policy prevent loading firmware (pre-allocated buffer) Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar
2018-05-17 14:48   ` Mimi Zohar

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=1526657376.3404.15.camel@linux.vnet.ibm.com \
    --to=zohar@linux.vnet.ibm.com \
    --cc=andresx7@gmail.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=casey@schaufler-ca.com \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=keescook@chromium.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=mcgrof@kernel.org \
    --cc=sds@tycho.nsa.gov \
    /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.