All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Matthew Garrett <mjg59@google.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH V3 1/2] security: Add a cred_getsecid hook
Date: Mon, 30 Oct 2017 13:03:47 -0400	[thread overview]
Message-ID: <1509383027.10174.5.camel@tycho.nsa.gov> (raw)
In-Reply-To: <CACdnJuu8fvVoD+G50dWtauUUa3H1tUAbBgzusc_CKNBugrVmwQ@mail.gmail.com>

On Mon, 2017-10-30 at 10:57 +0000, Matthew Garrett via Selinux wrote:
> On Thu, Oct 26, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On Thu, 2017-10-26 at 01:40 -0700, Matthew Garrett via Selinux
> > wrote:
> > > +static void selinux_cred_getsecid(const struct cred *c, u32
> > > *secid)
> > > +{
> > > +     rcu_read_lock();
> > > +     *secid = cred_sid(c);
> > > +     rcu_read_unlock();
> > 
> > Is rcu_read_lock() necessary here? Seems like we use cred_sid() in
> > many
> > places without it.
> 
> Ah, I thought it was based on task_sid(), but I guess that's actually
> protecting the __task_cred()?

It appears to me that in all other cases, we are either dealing with
the current cred, or something in the call chain of cred_sid() is
holding a reference to the cred, or something in the call chain of
cred_sid() has called rcu_read_lock() already.  I might have missed
something though, and I don't know how safe it is to assume that all
future callers will do this.  cc'd David for his thoughts.

WARNING: multiple messages have this Message-ID (diff)
From: sds@tycho.nsa.gov (Stephen Smalley)
To: linux-security-module@vger.kernel.org
Subject: [PATCH V3 1/2] security: Add a cred_getsecid hook
Date: Mon, 30 Oct 2017 13:03:47 -0400	[thread overview]
Message-ID: <1509383027.10174.5.camel@tycho.nsa.gov> (raw)
In-Reply-To: <CACdnJuu8fvVoD+G50dWtauUUa3H1tUAbBgzusc_CKNBugrVmwQ@mail.gmail.com>

On Mon, 2017-10-30 at 10:57 +0000, Matthew Garrett via Selinux wrote:
> On Thu, Oct 26, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On Thu, 2017-10-26 at 01:40 -0700, Matthew Garrett via Selinux
> > wrote:
> > > +static void selinux_cred_getsecid(const struct cred *c, u32
> > > *secid)
> > > +{
> > > +?????rcu_read_lock();
> > > +?????*secid = cred_sid(c);
> > > +?????rcu_read_unlock();
> > 
> > Is rcu_read_lock() necessary here? Seems like we use cred_sid() in
> > many
> > places without it.
> 
> Ah, I thought it was based on task_sid(), but I guess that's actually
> protecting the __task_cred()?

It appears to me that in all other cases, we are either dealing with
the current cred, or something in the call chain of cred_sid() is
holding a reference to the cred, or something in the call chain of
cred_sid() has called rcu_read_lock() already.  I might have missed
something though, and I don't know how safe it is to assume that all
future callers will do this.  cc'd David for his thoughts.

--
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

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Matthew Garrett <mjg59@google.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	linux-security-module@vger.kernel.org, selinux@tycho.nsa.gov,
	David Howells <dhowells@redhat.com>
Subject: Re: [PATCH V3 1/2] security: Add a cred_getsecid hook
Date: Mon, 30 Oct 2017 13:03:47 -0400	[thread overview]
Message-ID: <1509383027.10174.5.camel@tycho.nsa.gov> (raw)
In-Reply-To: <CACdnJuu8fvVoD+G50dWtauUUa3H1tUAbBgzusc_CKNBugrVmwQ@mail.gmail.com>

On Mon, 2017-10-30 at 10:57 +0000, Matthew Garrett via Selinux wrote:
> On Thu, Oct 26, 2017 at 3:20 PM, Stephen Smalley <sds@tycho.nsa.gov>
> wrote:
> > On Thu, 2017-10-26 at 01:40 -0700, Matthew Garrett via Selinux
> > wrote:
> > > +static void selinux_cred_getsecid(const struct cred *c, u32
> > > *secid)
> > > +{
> > > +     rcu_read_lock();
> > > +     *secid = cred_sid(c);
> > > +     rcu_read_unlock();
> > 
> > Is rcu_read_lock() necessary here? Seems like we use cred_sid() in
> > many
> > places without it.
> 
> Ah, I thought it was based on task_sid(), but I guess that's actually
> protecting the __task_cred()?

It appears to me that in all other cases, we are either dealing with
the current cred, or something in the call chain of cred_sid() is
holding a reference to the cred, or something in the call chain of
cred_sid() has called rcu_read_lock() already.  I might have missed
something though, and I don't know how safe it is to assume that all
future callers will do this.  cc'd David for his thoughts.

  reply	other threads:[~2017-10-30 17:03 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-26  8:40 [PATCH V3 1/2] security: Add a cred_getsecid hook Matthew Garrett
2017-10-26  8:40 ` Matthew Garrett
2017-10-26  8:40 ` [PATCH V3 2/2] IMA: Support using new creds in appraisal policy Matthew Garrett
2017-10-26  8:40   ` Matthew Garrett
2017-10-26  9:11   ` James Morris
2017-10-26  9:11     ` James Morris
2017-11-28 20:48   ` Mimi Zohar
2017-11-28 20:48     ` Mimi Zohar
2017-11-28 20:48     ` Mimi Zohar
2017-11-28 21:22     ` Matthew Garrett
2017-11-28 21:22       ` Matthew Garrett
2017-11-28 21:35       ` Mimi Zohar
2017-11-28 21:35         ` Mimi Zohar
2017-11-28 21:35         ` Mimi Zohar
2017-11-28 21:37         ` Matthew Garrett
2017-11-28 21:37           ` Matthew Garrett
2017-11-28 22:33           ` Mimi Zohar
2017-11-28 22:33             ` Mimi Zohar
2017-12-15 22:24             ` Matthew Garrett
2017-12-15 22:24               ` Matthew Garrett
2017-12-15 22:35               ` Matthew Garrett
2017-12-15 22:35                 ` Matthew Garrett
2017-12-18 15:39                 ` Mimi Zohar
2017-12-18 15:39                   ` Mimi Zohar
2017-12-18 15:39                   ` Mimi Zohar
2017-10-26  9:04 ` [PATCH V3 1/2] security: Add a cred_getsecid hook James Morris
2017-10-26  9:04   ` James Morris
2017-10-26 13:21 ` Casey Schaufler
2017-10-26 13:21   ` Casey Schaufler
2017-10-30 10:54   ` Matthew Garrett
2017-10-30 10:54     ` Matthew Garrett
2017-10-26 14:20 ` Stephen Smalley
2017-10-26 14:20   ` Stephen Smalley
2017-10-26 14:20   ` Stephen Smalley
2017-10-30 10:57   ` Matthew Garrett
2017-10-30 10:57     ` Matthew Garrett
2017-10-30 17:03     ` Stephen Smalley [this message]
2017-10-30 17:03       ` Stephen Smalley
2017-10-30 17:03       ` Stephen Smalley
2017-11-14 19:42       ` Matthew Garrett
2017-11-14 19:42         ` Matthew Garrett

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=1509383027.10174.5.camel@tycho.nsa.gov \
    --to=sds@tycho.nsa.gov \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mjg59@google.com \
    --cc=selinux@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.