netdev - Re: [PATCH 1/6] Security: define security_sk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 10 Aug 2011 08:49:53 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	Rongqing Li <rongqing.li@...driver.com>
Cc:	Casey Schaufler <casey@...aufler-ca.com>, netdev@...r.kernel.org,
	selinux@...ho.nsa.gov, linux-security-module@...r.kernel.org
Subject: Re: [PATCH 1/6] Security: define security_sk_getsecid.

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@...driver.com wrote:
> >>>> From: Roy.Li<rongqing.li@...driver.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

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