[Bro-Dev] changing Notice::policy mechanism

Seth Hall seth at icir.org
Mon Nov 5 10:35:56 PST 2012

On Nov 5, 2012, at 12:13 PM, Vern Paxson <vern at icir.org> wrote:

>> I think the construct we need to solve the problem already exists purely in the script-layer:
>>    type TriggerFunc: function(n: Notice::Info): bool;
>>    global Notice::policy: vector of set[TriggerFunc];
> That doesn't have the attribute that I think we likely want, namely an
> explicit "switch" on the particular notice type.
> Sepaking of which, maybe we don't want an exact split-case-by-case but
> rather something a bit broader.  Here I'm thinking of policies that I'd
> like to apply to any Notice of n different types; it's important to not
> have to replicate that code, but instead just list the n types and the
> associated predicate.

This is getting at the heart of what I think I want.  Being able to define a notice type or notice types and apply an action is the end result, but how you implement the support for that in the script layer is currently too complicated.  Optimally, I think it would be nice if people never had to use the action notice policy and that was why I wrote those "cheater" variables… Notice::ignored_types, Notice::emailed_types, Notice::alarmed_types, etc.  The problem is, is that I think that no matter what "cheater" variables we create people will always need to be more expressive (that's been my experience with the few variables I already created).  

What I'm pressing for is that make that next step more obvious because it would be a familiar Bro experience.  Also, the implementation of that support in the script layer would be a lot clearer.  Right now, there is a lot of code just to support the policy mechanism in the notice framework.


Seth Hall
International Computer Science Institute
(Bro) because everyone has a network

More information about the bro-dev mailing list