RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[Venkat Yekkirala]

> My main concern with these patches is that moving the 
> NetLabel check out
> of selinux_socket_sock_rcv_skb() and into 
> selinux_skb_policy_check() (as
> it is currently written) would force us to compare a packet's NetLabel
> with either the IPsec label or the secmark label

Yes you would do these checks (while using a netlabel based off of the
secmark at that point) to enforce flow control and when they succeed,
you will copy netlabel into secmark.

> and not the socket's
> label.

The socket Vs. secmark check that happens later in rcv_skb will in fact be
looking at the cipso label that is by then a part of the secmark context.

>  The ability to make access decisions based on the process
> consuming the data and the data itself it one of the nicer 
> qualities of
> NetLabel in my opinion.

This nicer quality ends up being preserved as explained above :)

We just need to get out of the mindset of viewing netlabel separately
once we are past the reconciliation point.

Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[Paul Moore]

Venkat Yekkirala wrote:
>>My main concern with these patches is that moving the 
>>NetLabel check out
>>of selinux_socket_sock_rcv_skb() and into 
>>selinux_skb_policy_check() (as
>>it is currently written) would force us to compare a packet's NetLabel
>>with either the IPsec label or the secmark label
> 
> Yes you would do these checks (while using a netlabel based off of the
> secmark at that point) to enforce flow control and when they succeed,
> you will copy netlabel into secmark.
> 
>>and not the socket's
>>label.
> 
> The socket Vs. secmark check that happens later in rcv_skb will in fact be
> looking at the cipso label that is by then a part of the secmark context.

So what you envison is that when an MLS label is found on a packet using
NetLabel the MLS label from the packet is attached to the secmark
context (replacing the existing MLS label, if any) and the resulting
context would be checked for a "flow_in" permission, yes?

Assuming the permission is granted the packet's secmark is replaced with
the updated context.  This updated secmark context would then be used in
sock_rcv_skb() to make an access decision, yes?

>> The ability to make access decisions based on the process
>>consuming the data and the data itself it one of the nicer 
>>qualities of
>>NetLabel in my opinion.
> 
> This nicer quality ends up being preserved as explained above :)

It wasn't clear to me from your patch or the "master plan" what you
intended to do with the NetLabel context.  I thought the "/* See if
CIPSO can flow in thru the current secmark here */" comment in your
patch was rather cryptic.

> We just need to get out of the mindset of viewing netlabel separately
> once we are past the reconciliation point.

Agreed.  Although to be honest, I think the NetLabel context can be
reconciled with the secmark and XFRM contexts just as easily using the
existing sock_rcv_skb() hook.  I guess I need to see where the
xfrm[4|6]_policy_check() hooks are called from in the stack to better
understand ...

-- 
paul moore
linux security @ hp

RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[Venkat Yekkirala]

> Assuming the permission is granted the packet's secmark is 
> replaced with
> the updated context.  This updated secmark context would then 
> be used in
> sock_rcv_skb() to make an access decision, yes?

You got it.

> 
> >> The ability to make access decisions based on the process
> >>consuming the data and the data itself it one of the nicer 
> >>qualities of
> >>NetLabel in my opinion.
> > 
> > This nicer quality ends up being preserved as explained above :)
> 
> It wasn't clear to me from your patch or the "master plan" what you
> intended to do with the NetLabel context.  I thought the "/* See if
> CIPSO can flow in thru the current secmark here */" comment in your
> patch was rather cryptic.

That was a test for you :)
> 
> > We just need to get out of the mindset of viewing netlabel 
> separately
> > once we are past the reconciliation point.
> 
> Agreed.  Although to be honest, I think the NetLabel context can be
> reconciled with the secmark and XFRM contexts just as easily using the
> existing sock_rcv_skb() hook.

Nope. That won't work for forwarded traffic.

>  I guess I need to see where the
> xfrm[4|6]_policy_check() hooks are called from in the stack to better
> understand ...

You are on the right path here.

RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[Venkat Yekkirala]

> I like these changes, but wondering why you haven't supplied 
> code for the 
> outbound case ?
> 
> 
> - James

The code for the outbound is still in the works. I hope to have it
out in a week or so.

RE: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[James Morris]

On Fri, 25 Aug 2006, Venkat Yekkirala wrote:

> > I like these changes, but wondering why you haven't supplied 
> > code for the 
> > outbound case ?
> > 
> > 
> > - James
> 
> The code for the outbound is still in the works. I hope to have it
> out in a week or so.

Ok, I guess we should wait until then before incorporating the patches 
(also, for Paul Moore to return and comment re. CIPSO).


- James
-- 
James Morris
<jmorris@namei.org>

Re: [PATCH 0/3] secid reconciliation-v01: Repost patchset with up dates

[Paul Moore]

James Morris wrote:
> On Fri, 25 Aug 2006, Venkat Yekkirala wrote:
>>>I like these changes, but wondering why you haven't supplied 
>>>code for the 
>>>outbound case ?
>>
>>The code for the outbound is still in the works. I hope to have it
>>out in a week or so.
> 
> Ok, I guess we should wait until then before incorporating the patches 
> (also, for Paul Moore to return and comment re. CIPSO).

My main concern with these patches is that moving the NetLabel check out
of selinux_socket_sock_rcv_skb() and into selinux_skb_policy_check() (as
it is currently written) would force us to compare a packet's NetLabel
with either the IPsec label or the secmark label and not the socket's
label.  The ability to make access decisions based on the process
consuming the data and the data itself it one of the nicer qualities of
NetLabel in my opinion.

Like James, I'd also like to see the outbound side too.

-- 
paul moore
linux security @ hp