All of lore.kernel.org
 help / color / mirror / Atom feed
* inode recognition in ipt_owner module
@ 2005-08-13 17:46 ori bar
  2005-08-15  6:27 ` Patrick Schaaf
  0 siblings, 1 reply; 2+ messages in thread
From: ori bar @ 2005-08-13 17:46 UTC (permalink / raw)
  To: netfilter-devel

ipt_owner as it currently is very problematic in matching packets from
a specific app.
(for those of us who want to use it "a-la personal firewall").

the current cmd matching is noit smart because it's only based on the
first 16 letters of a filename, and that can easily be spoofed.

I was wondering, it may be possible to an inode based matching, from
what i've read in the /proc/xxx/exe mechanism source code, all it
takes, is using the pid to get access to a list of file mappings, from
them, take the first executable mapping, from it, get the dentry, from
dentry get inode, and from inode get i_ino which should be the inode
number. This may allow us to better define "app-based rules".

Is there already something like this somewhere in netfilter?
Does anybody want me to try implementing it and send it somewhere
(notice: i never developed kernel modules, i only read them so far, so
i may need some help here)?

Thanks in advance and have a nice day 

-- 
1110101111111110 - it's a way of life

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: inode recognition in ipt_owner module
  2005-08-13 17:46 inode recognition in ipt_owner module ori bar
@ 2005-08-15  6:27 ` Patrick Schaaf
  0 siblings, 0 replies; 2+ messages in thread
From: Patrick Schaaf @ 2005-08-15  6:27 UTC (permalink / raw)
  To: ori bar; +Cc: netfilter-devel

Hello ori,

> ipt_owner as it currently is very problematic in matching packets from
> a specific app.

This is correct. Soon it will be impossible. The feature is just being
removed from ipt_owner. iptables operates on the IP router level.

> (for those of us who want to use it "a-la personal firewall").

Personal firewalls are insecure by design. Bad applications can
easily write their bad code to a different executable name,
and start that.

> Does anybody want me to try implementing it and send it somewhere
> (notice: i never developed kernel modules, i only read them so far, so
> i may need some help here)?

The people who constantly develop kernel modules, have the opinion
that it cannot be done properly. So they are removing it altogether.

Your chances to do it, never having developed kernel modules, are 0.

And even if you were to succeed, you would now have to maintain and
distribute the changes on your own.

best regards
  Patrick

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-08-15  6:27 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-08-13 17:46 inode recognition in ipt_owner module ori bar
2005-08-15  6:27 ` Patrick Schaaf

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.