On 11/01/2012 03:35 PM, Seth Hall wrote:
> I've discussed changing the Notice::policy notice handling mechanism with a
> few people and I think that generally everyone agrees that the current
> mechanism, while very powerful, sucks from a usability perspective. This is
> a good thing to address now since we're either on the precipice of repeating
> a mistake to more frameworks or adapting to a style that is easier to
> understand. I'm going to give an example of how I think it could work in an
> evented model now. Please shoot holes. :)
>
> These implement the decidedly silly case of sending a notice to an email if
> the SSH connection originated locally.
>
> event Notice::policy(n: Notice::Info)
> {
> if ( n$note == SSH::Login &&
> Site::is_local_host(n$id$orig_h) )
> {
> add n$actions[Notice::ACTION_EMAIL];
> }
> }
>
> That would be replacement to the current model of this:
>
> redef Notice::policy += {
> [$pred(n: Notice::Info) = {
> return ( n$note == SSH::Login &&
> Site::is_local_host(n$id$orig_h) );
> },
> $action = Notice::ACTION_EMAIL],
> };
>
> Here are some random thoughts about these two approaches in no particular
> order:
>
> - The evented model (top one) is more Bro-y and easier which is a BIG plus.
>
> - The PolicyItem model (bottom one) has the ability to halt further
> processing with the $halt attribute of PolicyItems. I don't think I'm
> convinced that this is a huge issue.
>
> - The evented model has latency from the event queue, but I don't think
> this is a huge issue. The latency is normally ok. Jon, is it an issue for
> the file analysis framework? I don't remember. The actions being applied
> would be processed through an event queue too so they will be processed after
> the policy events anyway.
>
> - Code block prioritization is built into the evented model using the
> &priority attribute. It's specifically implemented for PolicyItem model.
>
> Any thoughts?
>
> .Seth
>
I like this idea (it seems MUCH easier to use). How would
"suppress_for" be implemented in the evented model?
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
