All of lore.kernel.org
 help / color / mirror / Atom feed
From: Justin McCann <jneilm@yahoo.com>
To: Jan Engelhardt <jengelh@computergmbh.de>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Get UID from netlink/conntrack
Date: Wed, 6 Feb 2008 19:28:41 -0800 (PST)	[thread overview]
Message-ID: <734077.89514.qm@web30406.mail.mud.yahoo.com> (raw)

----- Original Message ----
> From: Jan Engelhardt <jengelh@computergmbh.de>
> >I'm attempting to make an auto-updating tcpdump filter, so
> >unprivileged users could tcpdump their own connections without
> >compromising privacy.
> 
> In that case, using ->f_uid should work for all (locally-generated)
> outgoing traffic. It is the best you can get right now.

I see that where /proc/net/tcp gets populated in net/ipv4/tcp_ipv4.c, the inode and uid use sock_i_uid() and sock_i_ino() for connections in TCP_SEQ_STATE_{LISTENING,ESTABLISHED}. Is there a reason to use ->f_uid instead?

That should get both incoming and outgoing, no? Or is the uid/inode not set up for outgoing connections in the SYN_SENT state? My question here is-- is there any chance I'd be notified of active-open/locally-initiated connections before the outgoing SYN packet gets sent?

> About input, a test would be needed (examining things) because I
> suspect that ssh sessions can be wrongly attributed to root when
> there's a normal user sitting behind it.

Right-- but although I'd like to see those connections as well, I'll take what I can get without too many changes. Clearly a problem for other applications.

> PID matching is not possible. Or rather, if it was, you'd spend a
> ridiculous amount of time scanning all processes' fd tables on every
> packet.

I was thinking the same thing, but the kernel has to actually queue up the data to socket. It would be nice if the sk_peercred actually got populated once the socket was created, but only for AF_UNIX. But then again, you can actually pass sockets between processes, so who owns it then? The PID isn't so important, just a nice-to-have.

Also, I only care to update the bpf filter when the connections change (which is exactly why conntrack is almost perfect for it), so I think/hope there shouldn't be any particular per-packet overhead. 

> And that's just the kernel side. How you wire that up in netlink
> is another story.

Yeah, about that....

    Justin


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

             reply	other threads:[~2008-02-07  3:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-07  3:28 Justin McCann [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-02-07  2:04 Get UID from netlink/conntrack Justin McCann
2008-02-07  2:14 ` Jan Engelhardt
2008-02-06 20:30 Justin McCann
2008-02-06 21:02 ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=734077.89514.qm@web30406.mail.mud.yahoo.com \
    --to=jneilm@yahoo.com \
    --cc=jengelh@computergmbh.de \
    --cc=netfilter-devel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.