I managed to inadvertently purge my ''Shorewall'' email folder recently :-( so I''m unable to reply directly to Ian''s last post on this subject. One of the complicating aspects of actions is that an action can (and often does) invoke other actions. The current algorithm for processing actions is: a) read /etc/shorewall/actions and /usr/share/shorewall/actions.std building a list of all defined actions. Each action''s definition file is scanned looking for references to other actions and a dependency graph is produced. For each <action>, a variable called requiredby_<action> lists the actions invoked by <action>. Any common policy actions are added to a "used actions" list and the corresponding action chain is created. b) As the rules file is being read, each invoked action is added to the "used actions list" (if it is not already on the list) and the associated action chain is created. c) The transitive closure of the "used actions list" is generated using the dependency graph produced during the first pass. d) For each action in the "used actions list", the corresponding action definition file is scanned and the action chain is populated. This algorithm extends somewhat naturally if we replace the "used actions list" by a list of used <action>:<log level> pairs. The algorithm gets really ugly though if we allow specifying a log level at the point where one action invokes another: /etc/shorewall/actions foo bar /etc/shorewall/foo bar:info .... Now if /etc/shorewall/rules contains: foo:debug ... Then we need to generate a foo:debug chain but not a bar:debug chain. But if /etc/shorewall/rules contains: foo:debug! ... Then we need both foo:debug and bar:debug chains. Life gets a lot simpler if we disallow specifying a log level when one action invokes another. I therefore propose that we adopt that restriction. Comments, -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> I managed to inadvertently purge my ''Shorewall'' email folder recently > :-( so I''m unable to reply directly to Ian''s last post on this > subject. > > One of the complicating aspects of actions is that an action can (and > often does) invoke other actions. The current algorithm for processing > actions is: > > a) read /etc/shorewall/actions and /usr/share/shorewall/actions.std > building a list of all defined actions. Each action''s definition file is > scanned looking for references to other actions and a dependency graph > is produced. For each <action>, a variable called requiredby_<action> > lists the actions invoked by <action>. > > Any common policy actions are added to a "used actions" list and the > corresponding action chain is created. > > > b) As the rules file is being read, each invoked action is added to the > "used actions list" (if it is not already on the list) and the > associated action chain is created. > > c) The transitive closure of the "used actions list" is generated using > the dependency graph produced during the first pass. > > d) For each action in the "used actions list", the corresponding action > definition file is scanned and the action chain is populated. > > This algorithm extends somewhat naturally if we replace the "used > actions list" by a list of used <action>:<log level> pairs. The > algorithm gets really ugly though if we allow specifying a log > level at the point where one action invokes another: > > /etc/shorewall/actions > > foo > bar > > /etc/shorewall/foo > > bar:info .... > > Now if /etc/shorewall/rules contains: > > foo:debug ... > > Then we need to generate a foo:debug chain but not a bar:debug chain. > But if /etc/shorewall/rules contains: > > foo:debug! ... > > Then we need both foo:debug and bar:debug chains. > > Life gets a lot simpler if we disallow specifying a log level when one > action invokes another. > > I therefore propose that we adopt that restriction.I may have been a little hasty here. If the requiredby_<action> list contains both the action and the log level used when the action is invoked, then the code isn''t *too* ugly. Using the above example: requiredby_foo="bar:info" So when we are generating the transitive closure when ''foo:debug'' appears in rules, the transitive closure of the used action list will be: "foo:debug bar:info" and when ''foo:debug!" is entered, the used action list will be: "foo:debug! bar:debug!" -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> Tom Eastep wrote: > >> I managed to inadvertently purge my ''Shorewall'' email folder recently >> :-( so I''m unable to reply directly to Ian''s last post on this >> subject. >> >> One of the complicating aspects of actions is that an action can (and >> often does) invoke other actions. The current algorithm for processing >> actions is: >> >> a) read /etc/shorewall/actions and /usr/share/shorewall/actions.std >> building a list of all defined actions. Each action''s definition file is >> scanned looking for references to other actions and a dependency graph >> is produced. For each <action>, a variable called requiredby_<action> >> lists the actions invoked by <action>. >> >> Any common policy actions are added to a "used actions" list and the >> corresponding action chain is created. >> >> >> b) As the rules file is being read, each invoked action is added to the >> "used actions list" (if it is not already on the list) and the >> associated action chain is created. >> >> c) The transitive closure of the "used actions list" is generated using >> the dependency graph produced during the first pass. >> >> d) For each action in the "used actions list", the corresponding action >> definition file is scanned and the action chain is populated. >> >> This algorithm extends somewhat naturally if we replace the "used >> actions list" by a list of used <action>:<log level> pairs. The >> algorithm gets really ugly though if we allow specifying a log >> level at the point where one action invokes another: >> >> /etc/shorewall/actions >> >> foo >> bar >> >> /etc/shorewall/foo >> >> bar:info .... >> >> Now if /etc/shorewall/rules contains: >> >> foo:debug ... >> >> Then we need to generate a foo:debug chain but not a bar:debug chain. >> But if /etc/shorewall/rules contains: >> >> foo:debug! ... >> >> Then we need both foo:debug and bar:debug chains. >> >> Life gets a lot simpler if we disallow specifying a log level when one >> action invokes another. >> >> I therefore propose that we adopt that restriction. > > > I may have been a little hasty here. > > If the requiredby_<action> list contains both the action and the log > level used when the action is invoked, then the code isn''t *too* ugly. > > Using the above example: > > requiredby_foo="bar:info" > > So when we are generating the transitive closure when ''foo:debug'' > appears in rules, the transitive closure of the used action list will be: > > "foo:debug bar:info" > > and when ''foo:debug!" is entered, the used action list will be: > > "foo:debug! bar:debug!" >The initial implementation is in the Shorwall2/ CVS project -- it has been lightly tested and I truely hope that you folks will help me test it because the changes were fairly extensive and risky. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Tue, Jul 27, 2004 at 07:38:09PM -0700, Tom Eastep wrote:> The initial implementation is in the Shorwall2/ CVS project -- it has > been lightly tested and I truely hope that you folks will help me test > it because the changes were fairly extensive and risky.What does this do (firewall.sh)? case ${#action} in 11) CHAIN=$(echo $action | cut -b -10)${actchain} ;; *) CHAIN=${action}${actchain} ;; esac I''m not sure what''s in $action; but, the code looks like it chops $action to 10 bytes only if it is exactly 11 bytes long. What''s wrong with 11 bytes that is okay for zero through 10 bytes and 12 bytes through infinity? Is this supposed to chop if action is .GE. 11 bytes? The code only handles .EQ. 11 bytes. -- -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/
Ian! D. Allen wrote:> On Tue, Jul 27, 2004 at 07:38:09PM -0700, Tom Eastep wrote: > >>The initial implementation is in the Shorwall2/ CVS project -- it has >>been lightly tested and I truely hope that you folks will help me test >>it because the changes were fairly extensive and risky. > > > What does this do (firewall.sh)? > > case ${#action} in > 11) > CHAIN=$(echo $action | cut -b -10)${actchain} > ;; > *) > CHAIN=${action}${actchain} > ;; > esac > > I''m not sure what''s in $action; but, the code looks like it chops > $action to 10 bytes only if it is exactly 11 bytes long. What''s wrong > with 11 bytes that is okay for zero through 10 bytes and 12 bytes > through infinity? Is this supposed to chop if action is .GE. 11 bytes? > The code only handles .EQ. 11 bytes. >chain names have a maximum length of 11 bytes and that is the documented maximum length of the name of an action. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net