In message <[EMAIL PROTECTED]>,
Risto Vaarandi writes:
>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.
I wasn't advocating a jump rule, a jump action works, and doing
variable substitution on the argument to the jump action could be a
good thing. E.G.
type=single
pattern = ... (\w+) (\w+)
action = jump rules_for_$1 $2
where an input line looks like:
tag ssh post_login ....
so it will jump to the post_login section of the ssh rules file.
The type=label rule is solely for determining a starting point in the
rules file.
E.G. rules_for_ssh may look like:
... bunch of rules
type = label
description = in_login
... more rules
type = label
description = post_login
... more rules for just messages that can occur post login
and the jump rules_for_ssh post_login would start in the middle of
the file.
>> 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 [...].
Why? Return returns up the call stack. No ambiguity AFAICT. It gotbes
to the rule with the jump action and continues processing from
there. Now there may be a problem for actions after the jump.
E.G.
action = jump a set_context_1; report context_1 "mail"
in this case, I would expect the report to use the contents of
context_1 as set by the rules executed by the jump. However there
maybe some things (like command line context/variable substutions)
that are done when the action is evaluated and not when the
inidividual action is executed. E.G.
action = jump a set_variable_f; report context_1 "%f"
What value is substituted for %f? The value before the jump, or the
value after the jump? I think it's the former but I could be wrong.
>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
Well that is always true right? The jump action taks an explicit label
to determine what rule file to use.
>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.
So:
type=single
description = 1-1
pattern = .*
action = jump a
type=single
description = 1-2
pattern = .*
action = jump a
(in a)
type=single
description = a-1
pattern = .*
action = none
acts as a return in a-1, and because the '1-1' rule doesn't have cont
= takenext, the 1-2 rule won't trigger, and the next file (say 2) will
be executed.
Where:
type=single
cont = takenext
description = 1-1
pattern = .*
action = jump a
type=single
description = 1-2
pattern = .*
action = jump a
(in a)
type=single
description = a-1
pattern = .*
action = none
will call a-1 and then go on to process 1-2.
But what happens if the 'a' ruleset wants to be able to select whether
1-2 should run? I suppose we could do something like:
type=single
cont = takenext
description = 1-1
pattern = .*
action = jump a
type = single
description = stop continuation
pattern = .*
context = takenext
action = delete takenext
type=single
description = 1-2
pattern = .*
action = jump a
(in a)
type=single
description = a-1
pattern = .*1$
action = none
type=single
description = a-2
pattern = .*
action = create takenext
if a-2 is triggered then rule 1-2 is executed. But if a-1 is
triggered, then 1-2 is not taken, 1-3 is taken and stops
evaluation of that rule file.
Compare this to:
type=single
description = 1-1
pattern = .*
action = jump a
type=single
description = 1-2
pattern = .*
action = jump a
(in a)
type=single
description = a-1
pattern = .*1$
action = jump RETURN_STOP
type=single
description = a-2
pattern = .*
action = jump RETURN_CONTINUE
where executing a-1 stops the evaluation of 1-2, but executing a-2
will trigger the evaluation of 1-2. I think this example reads better
and reduces the rule clutter.
>>> 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).
Yeah I am not sure that is a win actually. With an explicit
type=callable, you could reuse the "myrules" description to concatente
rules files in order if you wanted. So the single nme for multiple
files doesn't require a cli interface.
>> P.S. any SEC users going to be at LISA in San Deigo next week?
>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 :(
Nope. Didn't even know about it.
--
-- 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
