Extending LOG target to display pid

Extending LOG target to display pid

[Nick Hay]

What I hoped to be an easy hack quickly ran into problems.  I planned to 
add an extra printk() in dump_packet() to output the pid, and perhaps 
the program executable number.  Since the owner module had access to the 
pid, I assumed there would be some way to get this information to the 
LOG module.  After a frustrating search through source code and 
documentation, I have the following questions:

1. For the owner module, where/how is the struct ipt_owner_info filled 
in for each packet?  In general, how is the ipt_entry_match/target data 
field filled in?

2. Any ideas on how I can get the pid of a local packet's creator in the 
log module?  I couldn't find any structures connected to the sk_buff 
that might contain it, and couldn't think of where the data would 
originally come from.

Actually... would current->pid work?

I'm still curious about question 1, though!

-- Nick Hay

Re: Extending LOG target to display pid

[Tobias DiPasquale]

On 7/5/05, Nick Hay <nickjhay@hotmail.com> wrote:
> 2. Any ideas on how I can get the pid of a local packet's creator in the
> log module?  I couldn't find any structures connected to the sk_buff
> that might contain it, and couldn't think of where the data would
> originally come from.

A security framework, with the proper auditing and accounting
mechanisms in place in the network stack could make this possible (any
it may already be). But in general, it would be quite a lot of work to
add the necessary code to the stack to account for the
sending/receiving PID at the correct stage. Unless you're doing MAC,
its probably not worth it.

> Actually... would current->pid work?

No, because there's no guarantee that the same process is on the CPU
by the time the packet hits your rule.

Can't check on #1 right now, but I believe that its filled in by the
module itself in whatever way it chooses.

-- 
[ Tobias DiPasquale ]
0x636f6465736c696e67657240676d61696c2e636f6d

Re: Extending LOG target to display pid

[Juha Heljoranta]

Nick Hay wrote:
> 2. Any ideas on how I can get the pid of a local packet's creator in the
> log module?  I couldn't find any structures connected to the sk_buff
> that might contain it, and couldn't think of where the data would
> originally come from.

You can copy-paste code from the owner match extension to LOG target to
implement it.

In short, you can do it but to make it pretty requires lot of work (and
knowledge).

You might find this helpful:
http://www.fsfe.org/Members/juha/thesis/thesis.pdf

FYI The owner match extension is just betting when it locates the packet
owner. Although, I admit that it bets right in ~99% of cases... :)

Some body at the netfilter-devel might known could the "socket hooks" be
used:
https://lists.netfilter.org/pipermail/netfilter-devel/2005-May/thread.html#19654

> Actually... would current->pid work?

No. The netfilter code executes quite often in interrupt context (e.g.
when sending tcp syn packets). The current macro might or might not
point to task that sends data.

Regards,
Juha Heljoranta

Re: Extending LOG target to display pid

[Nick Hay]

Tobias DiPasquale wrote:
> On 7/5/05, Nick Hay <nickjhay@hotmail.com> wrote:
> 
>>2. Any ideas on how I can get the pid of a local packet's creator in the
>>log module?  I couldn't find any structures connected to the sk_buff
>>that might contain it, and couldn't think of where the data would
>>originally come from.
> 
> 
> A security framework, with the proper auditing and accounting
> mechanisms in place in the network stack could make this possible (any
> it may already be). But in general, it would be quite a lot of work to
> add the necessary code to the stack to account for the
> sending/receiving PID at the correct stage. Unless you're doing MAC,
> its probably not worth it.

My original intention was to replicate some part of Windows' ZoneAlarm
package: the ability to recognise which program was asking for access,
and to filter based on that.  Noticing a strange packet that was blocked
by my filter on outgoing ports, and not being able to find out where it
came from was the immediate motivation :)

Is it better to try this at the SELinux level,
blocking/monitoring/adjusting access to socket creation/use?

>>Actually... would current->pid work?
> 
> No, because there's no guarantee that the same process is on the CPU
> by the time the packet hits your rule.
>
> Can't check on #1 right now, but I believe that its filled in by the
> module itself in whatever way it chooses.

-- Nick

Re: Extending LOG target to display pid

[Jonas Berlin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Quoting Nick Hay on 2005-07-05 23:56 UTC:
> My original intention was to replicate some part of Windows' ZoneAlarm
> package: the ability to recognise which program was asking for access,
> and to filter based on that.  Noticing a strange packet that was blocked
> by my filter on outgoing ports, and not being able to find out where it
> came from was the immediate motivation :)

I made this kind of program some years ago ; it pops up a window if some
yet-unknown program tries to access anything.. You then have the options
to create a rule on-the-fly if you want or just accept/reject that
specific packet. It uses the QUEUE target of iptables which sends the
whole packet to userspace. I have tweaked the kernel code to send the
PID as well. This whole thing has only been tested with outgoing
connections, and it worked well.

It isn't user-friendly like ZoneAlarm, but it sure is hacker-friendly :)

I have three clients implemented, one text-based (for desperate console
hacking), one gtk-based written in C and one java-gnome-based (gtk
wrapper lib for java) written in Java. The Java one has the most
features. It would probably not be too hard to rewrite the java version
for some other toolkit like Swing or SWT.

Here's some screenshots, the first one from the java-gnome version and
the second from the C-gtk version:

  http://xkr47.outerspace.dyndns.org/tmp/firefly-java-1.png
  http://xkr47.outerspace.dyndns.org/tmp/firewall-layout-5.png

If you are interested I could pack it up for you..

- --
- - xkr47
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCzMxxxyF48ZTvn+4RAo/VAJ9Rxw8mc483cOMz/zvvWlGikz7ycACeIuWN
/yLfUiUvzg7pcKJHwDeb/gY=
=UALz
-----END PGP SIGNATURE-----