From: Paul Moore <paul.moore@hp.com>
To: Venkat Yekkirala <vyekkirala@TrustedCS.com>
Cc: netdev@vger.kernel.org, selinux@tycho.nsa.gov, eparis@redhat.com,
jmorris@namei.org, sds@tycho.nsa.gov
Subject: Re: [PATCH v4 1/2] NetLabel: secid reconciliation support
Date: Wed, 04 Oct 2006 15:27:55 -0400 [thread overview]
Message-ID: <45240B3B.3040603@hp.com> (raw)
In-Reply-To: <36282A1733C57546BE392885C0618592015CF939@chaos.tcs.tcs-sec.com>
Venkat Yekkirala wrote:
>> * XFRM present
>>
>> xfrm_sid = <full context from xfrm>
>> loc_sid = SECINITSID_NETMSG
>> nlbl_sid = SECSID_NULL/0
>> ext_sid = xfrm_sid
>> final skb->secmark = avc_ok : ext_sid ? unchanged
>>
>> * NetLabel present
>>
>> xfrm_sid = SECSID_NULL/0
>> loc_sid = SECSID_NULL/0
>> nlbl_sid = <SECINITSID_NETMSG te ctx, netlabel mls ctx>
>> ext_sid = nlbl_sid
>> final skb->secmark = avc_ok : ext_sid ? unchanged
>
> I was referring to the differences in what getpeercon would
> return in the above 2 scenarios.
>
> In the xfrm case: final skb->secmark would be 0 resulting in getpeercon
> to return EPROTONOOPT
In the "XFRM present" case above if the access is allowed (avc_ok is
true) then the final skb->secmark value is going to be set to the value
of ext_sid which is the xfrm_sid. Any calls made to getpeercon() would
return success with the context matching xfrm_sid.
I have a hunch we are still on different pages here ...
> In the NetLabel case: final skb->secmark would be network_t resulting in
> getpeercon to return network_t
Yep, and I understand you would like to see it as unlabeled_t. I think
we both have valid arguments for either case and we are just waiting to
hear from others.
--
paul moore
linux security @ hp
next prev parent reply other threads:[~2006-10-04 19:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-04 19:02 [PATCH v4 1/2] NetLabel: secid reconciliation support Venkat Yekkirala
2006-10-04 19:27 ` Paul Moore [this message]
2006-10-04 19:45 ` Stephen Smalley
-- strict thread matches above, loose matches on Subject: below --
2006-10-04 19:53 Venkat Yekkirala
2006-10-04 20:08 ` Paul Moore
2006-10-04 19:37 Venkat Yekkirala
2006-10-04 19:52 ` Paul Moore
2006-10-04 17:09 Venkat Yekkirala
2006-10-04 16:59 Venkat Yekkirala
2006-10-04 18:45 ` Paul Moore
2006-10-04 15:46 [PATCH 0/2] [PATCH 0/2] Updated NetLabel/secid-reconciliation bits and a bugfix paul.moore
2006-10-04 15:46 ` [PATCH v4 1/2] NetLabel: secid reconciliation support 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=45240B3B.3040603@hp.com \
--to=paul.moore@hp.com \
--cc=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=netdev@vger.kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=vyekkirala@TrustedCS.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).