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
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
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
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
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
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
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
> > 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
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
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
10 matches
Mail list logo