Re: [patch] Socket Receive Hook

cvanceat_private

Attached is the same patch in a slightly more friendly format. To address
my own concerns, with this patch, I was able to succesfully perform all
the checks we require for UDP/TCP input processing.

We could have copied the netdev security information into the skb security
context, but I've been holding off using the skbuff security field until
we have true packet labeling (IPSEC or some alternative).

To recap, this patch defines one new hook and places it in two places in
the network input path (one for TCP and one for UDP/RAW/etc). We use it to
check receive, connect, and accept permissions once the socket has been
associated with the incoming skbuff.

To anyone using this hook, I should add that we are seeing TCP_TIME_WAIT
messages that do not have a valid struct socket stored in the struct sock.
The pointer isn't NULL, it is simply invalid.  We believe this is due to
the way the kernel casts the struct sock to a struct tcp_tw_bucket when
handing the timed wait.

I didn't include a comment in the patch, but we should probably say
something to the affect (wherever we are putting such warnings):

Note that sk->socket may not be safely dereferenced in all cases.  If
sk->state == TCP_TIME_WAIT, the pointer may be non-NULL, but still
invalid.

Otherwise, does anyone have any issues with the acceptance of this patch?

chris.

On Fri, 10 Aug 2001, James Morris wrote:
> On Thu, 9 Aug 2001, Chris Vance wrote:
>
> > We would also like to insert another hook into tcp_rcv_state_process
> > <new/ipv4/tcp_input.c> so that we may perform tcp connection checking
> > (separate from this patch). The problem is that by the point that routine
> > is called, the skb->dev field has been set to NULL.  Our current checks
> > require socket and netdevice security fields.  Can anyone suggest an
> > alternative?
> >
>
> Can you copy the netdev security information into the skb security context
> lower down in the stack?
>
> This is the intention of the skb security context, to propagate security
> context between layers.