Re: fireflier firewall userspace program doing userspace packet filtering

[Luke Kenneth Casson Leighton]

regarding this issue, i have done some exploration and found that
ipt_owner is capable of registering by pid.

therefore, the naive approach considered was to have fireflier
"vet" rules via its userspace rules dynamically creating per-pid
_new_ and _real_ rules (based on the template of options specified
from the corresponding userspace rule) but of course with the
ipt_owner "pid" set.

this would at first glance solve the "INCOMING" problem which i
understand the present ipt_owner code to be suffering from.

anyway - this approach is insufficient and fraught with
difficulties, not least involving purging the queue of existing
packets that _would_ match the newly created rule, but it's
too late, they're already in the queue.

etc.

so, what i would like to consider doing is to modify the ipt_owner
module to include the full pathname of the binary it is supposed to
vet.

i don't give a rat's monkeybutt about "oo, yuk, that's disgusting
to do that in the kernel" or "that would _so_ slow network traffic
down": i don't care: this is going in an selinux system where the
performance hit of selinux has already been accepted, so a couple
more percentage performance hit i really don't give a stuff.


so, my question, therefore, is:

	what should i record in a modified version of ipt_owner in
	order to "vet" packets on a per-executable basis?

	should i consider recording the inode of the program's binary?

	should i consider recording the _name_ of the program?

	if i record the inode number, what example code should i examine
	in order to DoTheRightThing of getting from process-pid to
	inode/program?

for example, i notice in ipt_owner.c that match_pid() calls
find_task_by_pid().   okkkaaay... so... and then in fs/proc/base.c's
proc_exe_link(), i see that get_task_mm() is called to get
something called an mm_struct.   and theeeennn... dget is called
on _that_, and _then_ in struct dentry, there's something called
a d_inode, and _that_ is what i presume contains the inode number
of the running process (i_ino).

am i along the right lines, or should i be (according to
proc_exe_link()) hunting down the struct vfsmount argument
with mntget() instead?  somehow i don't think so, but i haven't
any point of reference to know in advance.

anyone with experience in the workings of proc and things, your
input and advice greatly appreciated.

l.


On Mon, Aug 30, 2004 at 11:42:02AM +0100, Luke Kenneth Casson Leighton wrote:

> 	is it possible to leverage - and i mean without cut/pasting
> 	large parts of kernel-space code into fireflier-in-userspace -
> 	the EXISTING kernel's iptables functionality in some way,
> 	such that per-program packet filtering may be performed?

> ultimate aim:
> 
> 	to be able to "enhance" existing iptables firewall rule
> 	checking rather than to be backed into a corner of "replacing"
> 	existing functionality.... just because of one extra check
> 	[the pid]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/