From: Stephen Smalley <sds@tycho.nsa.gov>
To: Rongqing Li <rongqing.li@windriver.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
netdev@vger.kernel.org, selinux@tycho.nsa.gov,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.
Date: Wed, 10 Aug 2011 08:49:53 -0400 [thread overview]
Message-ID: <1312980593.21048.12.camel@moss-pluto> (raw)
In-Reply-To: <4E41DDEB.9040904@windriver.com>
On Wed, 2011-08-10 at 09:24 +0800, Rongqing Li wrote:
> On 08/10/2011 08:57 AM, Casey Schaufler wrote:
> > On 8/9/2011 5:43 PM, Rongqing Li wrote:
> >> On 08/10/2011 12:13 AM, Casey Schaufler wrote:
> >>> On 8/9/2011 12:28 AM, rongqing.li@windriver.com wrote:
> >>>> From: Roy.Li<rongqing.li@windriver.com>
> >>>>
> >>>> Define security_sk_getsecid to get the security id of a sock.
> >>>
> >>> Why are you requesting the secid when you're just going to
> >>> use it to get the secctx? Why not ask for that directly?
> >>> Is there ever a case where you only want the secid?
> >>>
> >> Hi:
> >>
> >> As I know, we have not method to get secctx directly.
> >
> > You are defining the method! Ask for what you want!
> >
> > The whole notion of secids is a holdover from the bad old
> > days when SELinux was a user space based enforcement mechanism.
> > The audit system was implemented when SELinux was the lone LSM
> > and unfortunately and unnecessarily propagated the use of secids.
> > If an object has a secid it must also have a secctx. The
> > interfaces that use secids could just as well use the secctx.
> > It is wasteful to create a new interface that fetches a secid
> > just to turn around and ask for the secctx in all cases.
> >
>
> Do you means I should write a method like below
> security_sk_getsecctx(struct sock *sk, char *secctx, int *len)?
>
> But secctx only is used to user. secid is used to source code to
> compute and compare the access permission.
>
> And I do not see the same method like
> security_task_getsecctx(). but security_task_getsecid() has been
> implemented in kernel source code.
Unlike Casey, I don't think secids are a bad idea or just a holdover -
we find them to be quite useful and efficient in SELinux. But in this
instance, he is correct that there is no reason to first fetch a secid
only to convert it into a context. There are other cases where you do
in fact want to avoid generating and managing the life cycle of a
security context string until you truly need it, and thus a secid makes
sense. So if you want to add a security_sk_getsecctx() hook, feel free.
There are some existing examples, e.g. security_inode_getsecctx() for
inodes, security_getprocattr() for tasks. Note that they use a slightly
different interface than what you describe above.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: Stephen Smalley <sds@tycho.nsa.gov>
To: Rongqing Li <rongqing.li@windriver.com>
Cc: Casey Schaufler <casey@schaufler-ca.com>,
netdev@vger.kernel.org, selinux@tycho.nsa.gov,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.
Date: Wed, 10 Aug 2011 08:49:53 -0400 [thread overview]
Message-ID: <1312980593.21048.12.camel@moss-pluto> (raw)
In-Reply-To: <4E41DDEB.9040904@windriver.com>
On Wed, 2011-08-10 at 09:24 +0800, Rongqing Li wrote:
> On 08/10/2011 08:57 AM, Casey Schaufler wrote:
> > On 8/9/2011 5:43 PM, Rongqing Li wrote:
> >> On 08/10/2011 12:13 AM, Casey Schaufler wrote:
> >>> On 8/9/2011 12:28 AM, rongqing.li@windriver.com wrote:
> >>>> From: Roy.Li<rongqing.li@windriver.com>
> >>>>
> >>>> Define security_sk_getsecid to get the security id of a sock.
> >>>
> >>> Why are you requesting the secid when you're just going to
> >>> use it to get the secctx? Why not ask for that directly?
> >>> Is there ever a case where you only want the secid?
> >>>
> >> Hi:
> >>
> >> As I know, we have not method to get secctx directly.
> >
> > You are defining the method! Ask for what you want!
> >
> > The whole notion of secids is a holdover from the bad old
> > days when SELinux was a user space based enforcement mechanism.
> > The audit system was implemented when SELinux was the lone LSM
> > and unfortunately and unnecessarily propagated the use of secids.
> > If an object has a secid it must also have a secctx. The
> > interfaces that use secids could just as well use the secctx.
> > It is wasteful to create a new interface that fetches a secid
> > just to turn around and ask for the secctx in all cases.
> >
>
> Do you means I should write a method like below
> security_sk_getsecctx(struct sock *sk, char *secctx, int *len)?
>
> But secctx only is used to user. secid is used to source code to
> compute and compare the access permission.
>
> And I do not see the same method like
> security_task_getsecctx(). but security_task_getsecid() has been
> implemented in kernel source code.
Unlike Casey, I don't think secids are a bad idea or just a holdover -
we find them to be quite useful and efficient in SELinux. But in this
instance, he is correct that there is no reason to first fetch a secid
only to convert it into a context. There are other cases where you do
in fact want to avoid generating and managing the life cycle of a
security context string until you truly need it, and thus a secid makes
sense. So if you want to add a security_sk_getsecctx() hook, feel free.
There are some existing examples, e.g. security_inode_getsecctx() for
inodes, security_getprocattr() for tasks. Note that they use a slightly
different interface than what you describe above.
--
Stephen Smalley
National Security Agency
next prev parent reply other threads:[~2011-08-10 12:49 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-09 7:28 [v2 PATCH 0/6] Export the sock's security context to proc rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:28 ` [PATCH 1/6] Security: define security_sk_getsecid rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 16:13 ` Casey Schaufler
2011-08-09 16:13 ` Casey Schaufler
2011-08-10 0:43 ` Rongqing Li
2011-08-10 0:43 ` Rongqing Li
2011-08-10 0:57 ` Casey Schaufler
2011-08-10 0:57 ` Casey Schaufler
2011-08-10 1:24 ` Rongqing Li
2011-08-10 1:24 ` Rongqing Li
2011-08-10 1:35 ` Casey Schaufler
2011-08-10 1:35 ` Casey Schaufler
2011-08-10 1:44 ` Rongqing Li
2011-08-10 1:44 ` Rongqing Li
2011-08-10 12:49 ` Stephen Smalley [this message]
2011-08-10 12:49 ` Stephen Smalley
2011-08-09 7:28 ` [PATCH 2/6] Define the function to write sock's security context to seq_file rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:28 ` [PATCH 3/6] Export the raw sock's security context to proc rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:28 ` [PATCH 4/6] Export the udp " rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:28 ` [PATCH 5/6] Export the unix " rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:28 ` [PATCH 6/6] Export the tcp " rongqing.li
2011-08-09 7:28 ` rongqing.li
2011-08-09 7:33 ` David Miller
2011-08-09 8:54 ` Rongqing Li
2011-08-09 8:54 ` Rongqing Li
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=1312980593.21048.12.camel@moss-pluto \
--to=sds@tycho.nsa.gov \
--cc=casey@schaufler-ca.com \
--cc=linux-security-module@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=rongqing.li@windriver.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.