Shorewall devel - Jul 2004 - Logging and Actions

Ian has proposed that we change the way that logging interacts with 
defined actions. Currently, if logging is specified on the invocation of 
an action (e.g., "AllowFTP:info all all"), all traffic sent to the 
AllowFTP chain is logged. In most cases, this isn''t what the user 
intended and other people have expressed surprise about this behavior in 
the past.

The way I see this working is that in process_actions1() and 
process_rules(), we keep track of the log levels (if any) that were used 
with each defined action. Then in process_actions2(), separate chains 
would be created for each log level (probably with manufactured names) 
that would treat each rule in the action as if it had the specified log 
level appended.

Example:

action.foo

	ACCEPT	-	-	tcp	22
	ACCEPT	-	-	udp	53

rules:

	foo		fw	net
	foo:info	net	fw

There would be two ''foo'' chains created:
''foo'' just as currently which
would be used for the first rule and a chain with a manufactured name 
that would look like it was created from this action.foo:

	ACCEPT:info	-	-	tcp	22
	ACCEPT:info	-	-	udp	53

This second chain would be the target of the second rule.

The first question that comes to mind is what do we do about this case?

action.bar:

	LOG:info		tcp	22

rules:

	bar:debug	all	all

My vote is to replace the log level in the rule with the one specified 
at invocation but I could also be talked into leaving the existing level 
alone.

Comments?
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Thu, Jul 15, 2004 at 02:39:08PM -0700, Tom Eastep
wrote:
> My vote is to replace the log level in the rule with the one specified 
> at invocation but I could also be talked into leaving the existing level 
> alone.
Why not sit on the fence and have it both ways?  Define a shorewall.conf
variable that lets us choose between the two behaviours.  Or (my
favourite), have a two syntaxes, e.g. "foo:info" does not over-ride
any existing levels in the action file and "foo:info!" does forcibly
over-ride existing log levels.

There will be action.foo files where it just isn''t appropriate to turn
on the logging for every rule in the file.  If you set things up so that
the only rules in action.foo files that get modified are the ones that
do *not* already have a log level, then a useful follow-on feature would
be to define a "do nothing" log level that protects some of the rules
in the action.foo file from having any logging added and keeps logging
disabled, e.g. for this action.foo:

        ACCEPT       -       -       tcp     22
	ACCEPT:warn  -       -       udp     53
	ACCEPT:none  -       -       udp    123

A normal (non-forcing) foo:info rule would only affect the first rule
in the above action.foo file - the the ACCEPT:warn would not be touched
and the ACCEPT:none would not be touched (but the "none" would protect
the entry from modification and mean no logging).

A forcing "foo:info!" rule would affect all three rules, adding
"info"
logging to all three rules in the action.foo file.

With forcing and non-forcing syntaxes, users can decide what they want.

-- 
-IAN!  Ian! D. Allen   Ottawa, Ontario, Canada
       EMail: idallen@idallen.ca   WWW: http://www.idallen.com/
       College professor via: http://teaching.idallen.com/
       Support free and open public digital rights:  http://eff.org/