netdev - Re: [RFC] netfilter: WIP: Xtables idletimer target implementation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 31 May 2010 22:12:59 +0300
From:	Luciano Coelho <luciano.coelho@...ia.com>
To:	ext Patrick McHardy <kaber@...sh.net>
Cc:	ext Jan Engelhardt <jengelh@...ozas.de>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Timo Teras <timo.teras@....fi>
Subject: Re: [RFC] netfilter: WIP: Xtables idletimer target implementation

On Mon, 2010-05-31 at 17:59 +0200, ext Patrick McHardy wrote:
> Luciano Coelho wrote:
> > On Fri, 2010-05-28 at 10:05 +0200, ext Jan Engelhardt wrote:
> >> On Friday 2010-05-28 07:25, Luciano Coelho wrote:
> >>> Do you have any other suggestion on how I can associate the rules to
> >>> specific interfaces?
> >> -A INPUT -i foo -j do
> >> -A do -j idletimer
> >>
> >> A little funny, but actually this would allow me to keep a timer
> >> for a group of interfaces rather than just per-if.
> > 
> > Yes, this is what our userspace apps are doing.  I've formulated my
> > question in an unclear way.  If you check the rest of the code, I create
> > sysfs files under the interface's directory and use it as an attribute
> > to notify the userspace when the timer has expired.
> > 
> > In short, I need to figure out a way to associate each rule with an
> > interface in sysfs, so I can notify the userspace when the timer has
> > expired.  I couldn't figure out another way to do it.  Any suggestions?
> 
> How about just using an arbitrary user-supplied name? People can
> name them after interfaces, or anything else.

I considered this option, but then I didn't find a proper place where to
include the attribute in sysfs, since I cannot add it as part of the
interface (eg. /sys/class/net/wlan0/idletimer) as I was doing before.
The other option would be to make the idletimer as part of the
xt_IDLETIMER module object in sysfs
(ie. /sys/module/xt_IDLETIMER/<user_supplied_name>), but it looks out of
place.  And I think adding it as /sys/class/net/idletimer is most likely
out of the question.

The latest "solution" I came up with, is to associate the idletimer with
every interface that it hits.  Whenever a packet arrives, I check which
interface it came from and add the timer to it (eg.
in /sys/class/net/wlan0/idletimer if the packet came via wlan0).  This
causes a bit extra processing per packet, but in most cases there
shouldn't be too many interfaces in the list, so the search should be
fairly quick.  And if performance becomes a problem, it can be worked
around by adding only one interface per ruleset, so the list will never
grow bigger than one node.

I think these two solutions would work.  I prefer the second one,
because we don't need to add the idletimer attribute in an artificial
place in sysfs.

The problem that remains with either solution is if the interface is
already idle when the rule created.  In that case, the timer won't start
(or at least will not be associated with that interface).  It will only
start when the first packet hits.  The only solution I see for this is
to add the interface name as an option to the target.  Maybe something
like "--autostart=wlan0"?

I'll send a new RFC patch soon with this ideas implemented, to better
express what I mean (C code can be easier to read than English :P)

-- 
Cheers,
Luca.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html