[Bro-Dev] changing Notice::policy mechanism

Daniel Thayer dnthayer at illinois.edu
Thu Nov 1 14:01:40 PDT 2012


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?



More information about the bro-dev mailing list