[apparmor] GSoC 2013, Kaan Özdinçer's proposal

[Seth Arnold]

I recently read Kaan's proposal for the Google Summer of Code, and
thought I should give him my feedback, as I did for Kshitij.

First, welcome Kaan. :)

> Timeline
> 
>     Read AppArmor documentation. Before Jun 17
>     Work on mentor's suggestions. Before Jun 17
>     Read aa-logprof and aa-genprof documentation Before Jun 17
>     Doing analysis on the interaction of rules within a profile as
>     well as how profiles interact. 1-2 weeks

Depending upon how well your first few profiling experiments go, this
may not take an entire two weeks; moving rules between a profile and
an abstraction is pretty straight forward. We don't often use the 'x'
domain transitions in abstractions, and limited the amount of write
access is given in abstractions, just to make understanding profiles a
little easier.

I think we will continue to keep some of these guidelines in mind --
putting domain transition 'x' rules in abstractions is a bit like a
non-local 'goto' in one function that can jump to the middle of another
function. (The analogy is certainly not perfect, but .. gives a good
feeling for what I think of the more complicated rule possibilities.)

>     Doing static analysis on applications to extract possible rules
>     and rule patterns. 1-2 weeks

Is this analysis on applications or on application profiles?

>     Creating a tool to merge multiple profiles together. 2 weeks

This is probably very optimistic. For simple cases, it might be
suitable, but profiles with different P/U/i X decisions, or different
child profiles, I think two weeks may be just sufficient to figure out
what the UI should look like. Actually doing it will probably take
longer.

>     Developing a better interface that will aid the user in being able
>     to find abstractions, and analyze inter-profile behavior. 2 weeks

This also feels optimistic. I could imagine something 'easy' being done
in two weeks, but I do not know if the results would be useful enough to
rely upon it. I'd love to be wrong here, though. :)

>     Update the existing YaST module to interface with the new profile
>     development tool. 2 weeks

This is definitely too little time. Consider making this one an optional
addition.

>     Announce them to community for review and getting contribution.
>     Last 3 weeks
>     Writing documentation. Last 1-2 weeks

Seems fair :)

> Technical details
> 
>     Doing analysis on the interaction of rules within a profile as
>     well as how profiles interact. This can be used to simplify rules,
>     suggest simplifications or abstrations, and discover potential
>     security holes in the provided policy.

Very much looking forward to this.

>     Creating a tool to merge multiple profiles together. Working
>     similar to logprof, but using profiles instead of a log as input.

Also this. :)

>     Developing a better interface that will aid the user in being able
>     to find abstractions, and analyze inter-profile behavior.

Yay!

>     Update the existing YaST module to interface with the new profile
>     development tool.

Existing YaST module code is truly gruesome. It had to meet some fairly
arbitrary constraints that made sense at the time but do not make sense
now. Also, the whole thing is written in Perl, and we'd very much like
new tools to be in Python. I don't know if YaST makes Python modules
easy, but I wouldn't pick our module as the starting point...

What feels like it is missing from this list is a logprof / genprof
replacement: authoring policies from ALLOWED or DENIED log entries. Our
existing tools are no longer maintainable and trying to add the cool
new features you've proposed here to the existing tools would be an
exercise in frustration and futility.

This is a truly unfortunate situation, since the cool new features are
definitely cooler and more fun to work on. But without a reasonably
reliable and stable base to build from, the cool tools are going to be
out of reach in a very frustrating sort of way.

So, if you've got the time to revise the proposal, please consider
setting aside more time for a tool for profile development from log
files, and perhaps doing so at the expense of the YaST module or
application analysis.

Thanks, and welcome :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20130506/5e0012ef/attachment-0001.pgp>