Subject: why is sk->skb->sk_socket->file NULL on incoming packets?

hi, simple question - if a userspace ip_queue program (fireflier)
can determine the pid of an incoming packet, why can't ipt_owner.c
do the same?

how do i force, even by using a userspace thing which asks the
packet to be "re-examined", the skb->sk->sk_socket->file to be
set?

i _need_ this to work!

_yes_ i have a modified version of ipt_owner.c which can track down
the full path name of the program.

_yes_ i'm happy with creating more than one per-executable-program-name
rule for instances where sockets are shared between executables
(e.g. they're passed over unix-domain-sockets).

help, help!

l.


--
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love. If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net"> lkcl.net </a> <br />
<a href="mailto:[email protected]"> [email protected] </a> <br />


2004-09-10 01:21:14

by Chris Wright

[permalink] [raw]
Subject: Re: why is sk->skb->sk_socket->file NULL on incoming packets?

* Luke Kenneth Casson Leighton ([email protected]) wrote:
> hi, simple question - if a userspace ip_queue program (fireflier)
> can determine the pid of an incoming packet, why can't ipt_owner.c
> do the same?
>
> how do i force, even by using a userspace thing which asks the
> packet to be "re-examined", the skb->sk->sk_socket->file to be
> set?

I assume the netfilter hook you come in on is NF_IP_LOCAL_IN? This is
at ip level. The sock (sk) is protocol specific, and hasn't been
looked up yet. Look at the protocols' input handlers (i.e. udp_rcv or
tcp_v4_rcv), they do this lookup (i.e. udp_v4_lookup or __tcp_v4_lookup).
The sk_filter() point is probably the first time you have an association
between the skb (inbound) and the sock it's going to be queued to.
LSM modules use security_sock_rcv_skb at this point.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

Subject: Re: why is sk->skb->sk_socket->file NULL on incoming packets?

On Thu, Sep 09, 2004 at 06:20:54PM -0700, Chris Wright wrote:
> * Luke Kenneth Casson Leighton ([email protected]) wrote:
> > hi, simple question - if a userspace ip_queue program (fireflier)
> > can determine the pid of an incoming packet, why can't ipt_owner.c
> > do the same?
> >
> > how do i force, even by using a userspace thing which asks the
> > packet to be "re-examined", the skb->sk->sk_socket->file to be
> > set?
>
> I assume the netfilter hook you come in on is NF_IP_LOCAL_IN? This is
> at ip level. The sock (sk) is protocol specific, and hasn't been
> looked up yet. Look at the protocols' input handlers (i.e. udp_rcv or
> tcp_v4_rcv), they do this lookup (i.e. udp_v4_lookup or __tcp_v4_lookup).
> The sk_filter() point is probably the first time you have an association
> between the skb (inbound) and the sock it's going to be queued to.
> LSM modules use security_sock_rcv_skb at this point.

oooo *wide-eyed*. thanks