[apparmor] Profile Templating

John Johansen john.johansen at canonical.com
Sun Mar 27 21:41:08 UTC 2011


On 03/27/2011 05:52 AM, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 27. März 2011 schrieb John Johansen:
>> On 03/26/2011 03:24 PM, Christian Boltz wrote:
> 
>>> As an example: logprof always adds new rules to the main profile.
>>> It should offer an option to add a rule to a include'd file.
>>
>> well not just that it would be nice if we had some smarts as to show
>> when rules are common across profiles.
> 
> ... and, while you are on it, if they come from an abstraction.

yes and that is actually part of the reason for changing how includes
work.
Currently they are handled as a preprocessor macro, just like in C
hence the #include.  So the parser actually has no notion of includes
being present it sees a flattened profile.

We need to make includes a first class citizen so that we can handle
them in a more intelligent way.  We could do this with the #include
syntax but it implies (at least to me) the preprocessor semantics
and all the nasty tricks you can do with them.

> 
>>>     #include content <bin.ping>
>>
>> thats and interesting idea
> 
> :-)
> 
>>> BTW: you can also "sell" the above grep command as a new shiny
>>> "aa_create_abstraction_from_profile" tool *g*
>>
>> hehe, well I don't know about that, but a better way to create
>> abstractions is needed and comming.  I have nearly finished enough of
>> the parser work that we can use the backend to analyze policy, so
>> that it can automatically show the grouping of common rules from all
>> the profiles, even when the rules contain regexes.
> 
> Sounds very useful :-)
> 
> For me, the most important usecase will probably be to keep my apache 
> vHosts/hats in sync without having to edit abstractions/whatever 
> manually. (To be exact: updating abstractions/whatever is the smaller 
> problem. Removing the now superfluous rule from all hats is what causes 
> more work.)
> 
>> The idea being feed it all the profiles, and it will dump back out
>> the sets with the rules for each set.
> 
>> {p1, p2, p3} {
>>   /rule3 w,
>> }
>>
>> This should help a lot in making abstractions.
> 
> Yes, indeed. As I wrote above, I'd like to see the following features:
> - show common rules shared by several profiles or hats (that's what you 
>   already wrote)
> - offer the option to write all or some of the rules to an abstraction 
>   file instead of the main profile.
>   It should be possible to
>   a) create a new abstraction file
>   b) update an existing abstraction file with the new rules
> - offer the option to remove all rules that are now in the abstraction
>   from the main profile ("cleanup" to keep the main profile short and 
>   readable). Basically it's the same thing that is already done when 
>   adding an abstraction to a profile with logprof.
> - The cleanup should also be available as separate command so that it 
>   can be run after manual changes in the abstractions.
>   Usecase: I'm using an auto-generated abstraction for each apache vhost 
>   which for example includes write permissions for 
>   /home/www/$domain/tmp/**.
>   It would be pointless if logprof changed one of those abstractions 
>   because they are auto-generated (and overwritten if I re-generate 
>   them), but I still need to remove rules added to the abstraction from 
>   the main profile.
> 
yep, and more actually.  I'd like to be able to tag a learning run, in some
way, as having a certain config option set.  So that we can start grouping
and making rules condition on config options, and of course doing the same
rule cleanup etc as for includes.

Also the same type of things for variables, let genprof know of a variable
and it finds/suggests rules it could be used in.  etc.

We could also go torward things like reordering log messages so all the
messages pertaining to a directory etc, are together so that it is easier
to see that you might want to do some globbing.

and the list goes on, and on.  I would really love to see some updated
tools.



More information about the AppArmor mailing list