> 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.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
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 unti
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 unti
> 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 t
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 l
> 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
