[apparmor] [patch] Add support for signal log events to aa-logprof

[Christian Boltz]

Hello,

Am Donnerstag, 26. November 2015 schrieb John Johansen:
> > this patch adds support for signal log events to aa-logprof. 
> >
> > In other words: this is the first new feature in aa-logprof since
> > I'm  working on the rule classes :-)
> >
> > In detail, this means:
> > - handle signal events in logparser.py
> > - "translate" those events in aa.py - from log (logparser.py
> > readlog()) to prelog (handle_children()) to log_dict 
> > (collapse_log()) to log_obj (ask_the_questions())
> >   (yes, really! :-/ - needless to say that this is ugly...)
> 
> you weren't kidding

I know :-/

The final goal is to have a SignalRuleset with the rules to add (if the 
user wants them), so the interesting question is if we can switch to 
SignalRuleset earlier.

Ideally we would already do it in logparser.py. "Unfortunately" it has a 
good reasons to use a hasher() because it is a cheap way to do de-
duplication of log events - it "just" overwrites a value in the hasher 
with another (actually the same) value if an event happens multiple 
times. (In other words: using SignalRuleset here already would probably 
have some performance impact.)

I'll have to check if it makes sense to switch to SignalRuleset in 
handle_children(). It doesn't check against the existing profile, so the 
question is if a SignalRule needs more RAM than an element in a hasher. 

A quick measurement with http://code.activestate.com/recipes/546530/ 
shows that a SignalRule uses about 2150 bytes, while a hasher containing
    hasher['/bin/foo']['send']['int']=True
needs about 1070 bytes (always assuming that this script knows how to 
calculate the memory usage correctly ;-)

I'm quite sure we can switch to SignalRuleset in collapse_log() (which 
also checks against the existing profile and ignores already-covered 
events) so that at least ask_the_question() wouldn't need to convert it. 

Actually we already create a temporary SignalRule in collapse_log() to 
check against the profile, so storing it in a SignalRuleset wouldn't be 
hard (and shouldn't be a real problem for memory usage).

This probably won't be the next patch I'll send, but I'll do it one day 
;-)

> I'm not fond of this. The translation is really ugly and the dict
> stuff and hand_children() make me want to cry (bad memories of the
> perl code).

I already wanted to cry when I waded through the code to find out where I 
need to add something for the signal log events. That's also the reason 
why I added the details to the patch description - now we have an in-bzr 
manual explaining how to add handling for other rule types ;-)


Regards,

Christian Boltz
-- 
> Meine Fonts füllen die komplette Wand, also könnte ich auch kein
> größeres Poster brauchen. :-)
Ich verwende für die Wände immer Tapete ;-)
[> Ratti und Christian Boltz]