From: Stephen Smalley <sds@tycho.nsa.gov>
To: Paul Moore <pmoore@redhat.com>
Cc: Milan Broz <gmazyland@gmail.com>, selinux@tycho.nsa.gov
Subject: Re: [PATCH] selinux: fix the default socket labeling in sock_graft()
Date: Thu, 10 Jul 2014 15:57:15 -0400 [thread overview]
Message-ID: <53BEF01B.9050504@tycho.nsa.gov> (raw)
In-Reply-To: <1828895.6E1loEUEHn@sifl>
On 07/10/2014 03:47 PM, Paul Moore wrote:
> On Thursday, July 10, 2014 01:45:55 PM Stephen Smalley wrote:
>> It seems a bit fragile though and certainly doesn't align with the
>> sock_graft hook documentation anymore. Wondering if we should assert
>> that sksec->sid is not SECINITSID_UNLABELED in the inet/inet6/unix case
>> (i.e. that sksec->sid has been set prior to copying it to isec->sid) ...
>
> Now that I'm changing the code I'm wondering if we could ever arrive at a
> situation where sksec->sid would legitimately end up as SECINITSID_UNLABELED
> in selinux_sock_graft(). In the normal case of no labeled networking, the
> sksec->sid label should end up as SECSID_NULL so I'm not to worried about
> that, but if would you get the SECINITSID_UNLABELED SID if you fed
> "...:unlabeled_t:..." into security_secctx_to_secid()? I'm pretty sure the
> answer is "no", but I haven't looked at that code in a while.
Yes, you can get back an initial SID from security_secctx_to_secid() if
the context string matches. In what scenario would sksec->sid be set to
the result of security_secctx_to_secid() on a context string though, and
from where would that context string originate? At most we only copy
the MLS attributes of the peer label, right?
next prev parent reply other threads:[~2014-07-10 19:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-10 15:37 [PATCH] selinux: fix the default socket labeling in sock_graft() Paul Moore
2014-07-10 16:56 ` Stephen Smalley
2014-07-10 17:45 ` Stephen Smalley
2014-07-10 19:11 ` Paul Moore
2014-07-10 19:47 ` Paul Moore
2014-07-10 19:57 ` Stephen Smalley [this message]
2014-07-10 20:57 ` Paul Moore
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=53BEF01B.9050504@tycho.nsa.gov \
--to=sds@tycho.nsa.gov \
--cc=gmazyland@gmail.com \
--cc=pmoore@redhat.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.