John P. Rouillard wrote: > In message <[EMAIL PROTECTED]>, > Risto Vaarandi writes: >> I have given it some thought and there are some at least some ways of >> doing this. There could be a special command line flag (e.g., -conf2) >> which loads a rule file, but doesn't use it for matching input lines by >> default. Instead, a user could employ the 'jump' action to tell SEC to >> use specific rule file only. > > That's probably the way I would go initially. Along with > > jump file [rulename or number] > > similar to how reset addresses individual rules. By default it would > start at the first rule in the file. Alternatively a new rule type: > > type = label > decription = a label to branch to.
After thinking a while, a separate rule type seems to be a better idea (at least at the moment, maybe things will look yet again differently after they have settled). At this moment I can think of the following arguments that favor a separate rule type: 1) many actions are triggered by a certain input line; however, that's not always the case -- what is the semantics of 'jump' in the Calendar rule, for example? The 'jump' rule type with a pattern, however, always makes a jump for matching input lines, 2) a jump rule always works faster than a jump action, because the latter involves variable substitution which is sometimes a complex operation. > > would identify the location to jump to in a file. It could also jump > into the current file at a given label as well to skip a series of > rules that can't possibly match. > > You also need a "jump return" action to return to the calling rule > sequence, similar to executing the RETURN target in iptables. > > Now the question is does the jumped ruleset occur in virtual parallel > (like multiple config files currently do) or in series with the > "caller" rules file? I was thinking of virtual parallelism... this, of course, makes the possible 'return' action semantics a bit more blurry, since in principle the rule file processing order depends on the character order on your system (on vast majority of the computer systems claims A < Z, a < z, and 0 < 9 always hold, but it could be different some day :). There is a simple way around this possible ambiguity, though - one can always write things down in a clear way by making jumps to individual files when order is important. Note that in that case the 'none' action in the matching rule will act as 'return' (provided that the 'continue' field equals to DontCont). Also, the jump rules could have their 'continue' fields set to TakeNext, in order to guarantee repeated redirections in a determined order. > > I don't have a real opinion on which is better. > > Also one other thing to look out for is jumping in a loop. > > so a rule in file a calls > > jump b > > and a rule in b calls > > jump a > > I think currently you can't get into a loop. Processing of every input > line will eventually exit. In one of my other posts on branching/flow > control I think I mentioned a mechanism to prevent loops by forcing > the call sequence to be a tree. But I am not sure if that is too > strict. well... currently this is impossible, but with jump rules it can happen... so there should be a mechanism for quitting the matching process if a loop is detected. (I have been thinking about it a bit, because an action loop issue could also occur for context-actions and there are specific mechanisms put to place for preventing this.) > >> Another way to enable branching would be to >> have 'load' and 'drop' actions for loading configuration from additional >> rule files at run time, and then let user to employ 'jump' for narrowing >> the matching process to given files only. > > I can see this being useful to load dynamic rules, but I think it's > less useful than statically specifying the files and using USR1 to do > the load/reload. > >> Instead of files, I've been >> thinking of using textual tags, e.g., 'load linux >> /etc/sec/linux/*.rules', 'jump linux', etc. (or >> -conf2=/etc/sec/linux/*.rules=linux which is somewhat similar to >> specifying input file contexts for SEC). > > I would kind of like the rules file to know that is is a callable > module. Maybe a new rule type: > > type = callable > description = myrules > > where the (optional) description is used as the "textual tag" for the > jump command. If they wanted a more descriptive name than a filename > would allow they can use the description field. This would occur as > the first rule in the branch/callable file (and could identify the > file as a callable file). If the description was missing, use the file > name (the part with directory names stripped off). > > I could live with the conf2= model as well as I could just use .csr > (callable sec rules) as an extension to differentiate from the .sr > (sec rules) files. One advantage of the command line approach is the ability to assign a single tag to the entire rule file pattern (in other words, set a tag for many files at once). > > P.S. any SEC users going to be at LISA in San Deigo next week? > I'd like to be there, but my schedule is currently too busy :( BTW, there is also a USENIX log analysis workshop (WASL08) taking place in San Diego (Dec 7, 2008) -- does anyone have plans attending it? I can only regret it is not held together with LISA :( br, risto > -- > -- rouilj > John Rouillard > =========================================================================== > My employers don't acknowledge my existence much less my opinions. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simple-evcorr-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
