[apparmor] GSoC proposal text v2

[John Johansen]

On 03/10/2013 05:56 PM, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 10. März 2013 schrieb John Johansen:
>> On 03/10/2013 07:54 AM, Christian Boltz wrote:
>>> Am Samstag, 9. März 2013 schrieb John Johansen:
> 
>>>> The base part of the project will be to implement a library and
>>>> basic
>>>> tool using the library that can develop a profile from logs files,
>>>
>>> +  (audit.log)
>>
>> hrmm what do you mean by audit.log? While log files is vague
>> (intentially), audit.log might be too specific. As that could be
>> construed as not working while syslog etc.
> 
> I just wanted to give a hint - of course syslog is also possible.
> 
>>>> The remainder of the project will be to extend the base library and
>>>> tool, in any of several possible directions:
>>>>
>>>> doing inter-rule and inter-profile static analysis,
>>>
>>> What do you mean with that?
>>
>> Ah, inter-rule analysis is analyzing the rules with in the profile,
>> so simplification, suggesting pattern matches, identifying potential
>> security problems (overlapping w and x). So what genprof/logprof
>> currently do and then some.
> 
> Ah, OK. Should we mention this in the description? (IMHO: yes, and it 
> should be a must-have)
> 
>> inter-profile would be doing that type of analysis between profiles.
>> So you could discover and pull out common abstractions, point out
>> potential security issues (overlapping w and x, alias or hardlink
>> rules that result in things being less secure, ...)
> 
> Especially the part about pulling out abstractions sounds useful ;-) but 
> nevertheless I'd call this optional.
> 
>>>> doing static analysis on applications
>>>> to extract possible rule patterns,
>>>
>>> In other words and extremely simplified:
>>>     strings /usr/bin/foo | grep /
>>> ? ;-)
>>
>> err yeah that could be a common pattern but I was hoping for more, 
>> like say noticing that a whole bunch of profiles are doing just read
>> accesses on  /usr/share/icons/ based files and suggesting that this
>> could be globbed maybe even made into/added to an include abstraction.
> 
> OK, so my understanding was correct - and there's a reason why I wrote 
> "extremely simplified" ;-)
> 
> Anyway, this might become interesting[tm] because if you want to get the 
> full picture, it will have to follow each library etc. - and OTOH it 
> should only honor the parts of a library that are actually used by the 
> application.
> 
> I have a feeling that running aa-logprof is easier and faster ;-)
> 
well yes and no,
the idea is that if we can do static analysis on applications we
can pull out all kinds of interesting things and seed the profile
development process, so you start with a pseudo profile to greatly
reduce the log traffic. It can also find corner cases that the application
may ask for but didn't during a regular profiling run.

That doesn't mean you won't want to examine what the static analyzer found
just like you would for the stream of log messages (ie you would feed its
output into genprof). Its really just another way to supplement profile
development.

>>>> or developing a better interface that will aid the user in being
>>>> able to find abstractions,
>>>
>>> That's already part of aa-logprof/aa-genprof, so I wouldn't put this
>>> in the part with optional stuff.
>>
>> Well I wanted to give some freedom of direction for a student. So if
>> they where really interested in doing profile analysis they could
>> focus on that, or if they are interested in human interface design
>> they could focus there.
> 
> There's nothing wrong with that as long as we get something that can 
> fully replace aa-logprof ;-)
> 
>>> I'd also
>>> +  The profile development tool should be written in Python or Go.
>>>
>>> (assuming Go is another programming language you'd like ;-)
>>
>> Well yes and no. Its a possibility and it is something that I am
>> supposed to learn, so its in the set of languages for maintenance.
> 
> BTW: would perl also be an option or do you want to get rid of it?
> 
I don't mind it for smaller utilities but I have found when the
utility gets larger it just gets harder and harder to maintain.
Python is the language most of the active developers are most familiar
with with Perl being very rusty for most of us.

>From an Ubuntu perspective perl is problematic as much of the perl
library is not available for core utilities that are part of the
install CD, so having it in perl would mean it would like not be
possible to put it on the CD image. I don't think that is a show
stopper for genprof/logprof but it does loose us flexibility there.

>>>> Skill Level: Intermediate - Hard (depends on implementation route)
>>>>
>>>> Mentor: John Johansen, Christian Boltz
>>>
>>> Looks like I might have a new "job" in the summer ;-)  No problem,
>>> but I'll probably forward the more technical questions to you.
>>
>> Right, well I expected it would be mostly be you acting as a second
>> point of contact. 
> 
> OK.
> 
>> And uh might explain things in more understandable
>> terms than me.
> 
> ;-)
> 
>> Alright and now for v2 of the text, I've taken most of Christian's
>> suggestions and reworded a few things to hopefully make them easier to
>> understand.
> 
> The text looks quite good, and the next round (after integrating some 
> of the things from above and the inline comments) could be the final 
> one ;-)
> 

Alright v3 below

---------------------------------------------------------

AppArmor profile development tool

Description: The AppArmor project is a MAC like security extension for
Linux. Its policy is based around profiles that are used to define the
set of permission an application will be granted.

The project goal is to implement a new smarter profile development tool,
that is better at creating abstractions, and inter-profile policy analysis.

The base part of the project will be to implement a library and basic tool
using the library that can develop a profile from audit log files, and basic
user interaction. This tool will replace the existing aa-logprof and
aa-genprof tools, which are unmaintained and out of date.

The remainder of the project will be to extend the base library and tool,
in any of several possible directions
* 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.
* doing static analysis on applications to extract possible rules and rule
  patterns. This can be used to preseed profile development by feeding
  the output into the base part of the project, and find program behavior
  that may not be discovered by standard execution on an application.
* creating a tool to merge multiple profiles together. Working similar
  to logprof, but using profiles instead of a log as input.
* developing a better interface that will aid the user in being able to find
  abstractions, and analyze inter-profile behavior.
* update the existing YaST module to interface with the new profile development
  tool.

Required knowledge: Python or Go,
Helpful knowledge: C and Perl as some components are written in these languages
                   YCP (if the student decides to update the YaST module as part
                   of depenent on implementation route), some knowledge of Perl
                   would be good but is not required

Skill Level: Intermediate - Hard (depends on implementation route)

Mentors: John Johansen, Christian Boltz

Student: