[Bro-Dev] changing Notice::policy mechanism

Seth Hall seth at icir.org
Thu Nov 1 19:28:38 PDT 2012


On Nov 1, 2012, at 5:47 PM, "Siwek, Jonathan Luke" <jsiwek at illinois.edu> wrote:

> It may be workable, but I think the latency does make things more complicated so it might not make sense to re-use this policy model for the file analysis framework, but that shouldn't be a showstopper for using it for notices.  I think it's fine to have the policy models be inconsistent, as long as both are easy to understand and use for their purpose.


As we discussed earlier and I never brought up in my overview, would it be better if we had some mechanism sitting between events and functions?  "Synchronous events"? "Multi-bodied functions"?  Here's an example of how a synchronous event might look at the script land…

global awesome: event(a: count) &synchronous;
global foobar: event(a: count);

event bro_init()
	{
	event foobar(1);
	event awesome(5);
	}

event awesome(a: count) &priority=5
	{
	print fmt("awesome: %d", a+5);
	}

event awesome(a: count) &priority=2
	{
	print fmt("awesome: %d", a+2);
	}

event foobar(a: count) 
	{
	print "foobar handler!";
	}


Assuming synchronous events existed, the output would be this:

awesome: 10
awesome: 7
foobar handler!

I would really kind of like to move away from this policy model.  The more I think about it, the less Bro-y it feels and I have trouble remembering how exactly to use them too (which I don't think bodes well for anyone!).  Focusing on simplicity and consistency at the script layer is something that we'll probably have to continue to struggle and fight for forever.  Although, I'm generally ok with complexity anywhere in Bro as long as we find a clear and obvious way to expose it to users.

  .Seth


--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/




More information about the bro-dev mailing list