[apparmor] GSoC proposal text v2

[Christian Boltz]

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 ;-)

> >> 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?

> >> 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 ;-)

> 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 the profiles
> interact, doing static analysis on applications to extract possible
> rules and rule patterns, creating a tool to merge multiple profiles
> into (working similar to logprof, but takes a profile instead of a

into _one_  - or drop "into"

> log as input) or developing a better interface that will aid the user
> in being able to find abstractions, and analyze inter-profile
> behavior.

This paragraph is probably better readable if you
- split it to a bullet list
- add a short description or example to every part

I'd also add "update the YaST module to work with the new code" as 
another point.

> 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:


Regards,

Christian Boltz
-- 
> > Danke an alle, die mir bei der Geburt geholfen haben, das Baby
> > brennt ;)
> Hat das weh getan, ein brennendes Baby zu gebären? *scnr* ;)))
Qualmt es der Mama neben dem Schenkel,
weiss der Opa, es gibt 'nen heißen Enkel!
[> Michael Raab und Thorsten von Plotho-Kettner in suse-linux]