[Bro-Dev] changing Notice::policy mechanism
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.
International Computer Science Institute
(Bro) because everyone has a network
More information about the bro-dev