Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-09 Thread Paul Moore
James Morris wrote: > On Thu, 9 Nov 2006, Paul Moore wrote: > >>It sounds like you have an idea of how you would like to see this implemented, >>can you give me a rough outline? Is this the partitioned SECMARK field you >>talked about earlier? > > No, just the fact that you are in the same kerne

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread James Morris
On Thu, 9 Nov 2006, Paul Moore wrote: > It sounds like you have an idea of how you would like to see this implemented, > can you give me a rough outline? Is this the partitioned SECMARK field you > talked about earlier? No, just the fact that you are in the same kernel address space and can rea

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread Paul Moore
James Morris wrote: > On Wed, 8 Nov 2006, Paul Moore wrote: > >>James Morris wrote: >> >>>On Wed, 8 Nov 2006, Paul Moore wrote: >>> 1. Functionality is available right now, no additional kernel changes needed 2. No special handling for localhost, I tend to like the idea of having consi

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread James Morris
On Wed, 8 Nov 2006, Paul Moore wrote: > James Morris wrote: > > On Wed, 8 Nov 2006, Paul Moore wrote: > > > >>1. Functionality is available right now, no additional kernel changes needed > >>2. No special handling for localhost, I tend to like the idea of having > >>consistent behavior for all ad

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread Paul Moore
James Morris wrote: > On Wed, 8 Nov 2006, Paul Moore wrote: > >>1. Functionality is available right now, no additional kernel changes needed >>2. No special handling for localhost, I tend to like the idea of having >>consistent behavior for all addresses/interfaces > > I don't agree. SO_PEERSEC

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread James Morris
On Wed, 8 Nov 2006, Paul Moore wrote: > 1. Functionality is available right now, no additional kernel changes needed > 2. No special handling for localhost, I tend to like the idea of having > consistent behavior for all addresses/interfaces I don't agree. SO_PEERSEC should always just work for

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread Paul Moore
Venkat Yekkirala wrote: >>>Fix SO_PEERSEC for tcp sockets to return the security context of >>>the peer (as represented by the SA from the peer) as opposed to the >>>SA used by the local/source socket. >> >>What about the case of a localhost TCP connection not using >>xfrm labeling? >> >>Joe Nall r

RE: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-08 Thread Venkat Yekkirala
> > Fix SO_PEERSEC for tcp sockets to return the security context of > > the peer (as represented by the SA from the peer) as opposed to the > > SA used by the local/source socket. > > What about the case of a localhost TCP connection not using > xfrm labeling? > > Joe Nall raised this as an import

Re: [PATCH 2/3] mlsxfrm: Various fixes

2006-11-07 Thread James Morris
On Tue, 7 Nov 2006, Venkat Yekkirala wrote: > Fix SO_PEERSEC for tcp sockets to return the security context of > the peer (as represented by the SA from the peer) as opposed to the > SA used by the local/source socket. What about the case of a localhost TCP connection not using xfrm labeling? Jo

[PATCH 2/3] mlsxfrm: Various fixes

2006-11-07 Thread Venkat Yekkirala
Fix SO_PEERSEC for tcp sockets to return the security context of the peer (as represented by the SA from the peer) as opposed to the SA used by the local/source socket. Signed-off-by: Venkat Yekkirala <[EMAIL PROTECTED]> --- include/linux/security.h| 14 ++ include/net/request_s