[apparmor] GSoC proposal text v2

[John Johansen]

On 03/10/2013 07:54 AM, Christian Boltz wrote:
> Hello,
> 
> Am Samstag, 9. März 2013 schrieb John Johansen:
>> Here is a first pass at a proposal to implement a new learning tool
>> for GSoC (Google Summer of Code)
> 
> Thanks for your text!
> 
> While it is probably very correct, it sounds quite technically and is 
> probably hard to understand for people that don't know AppArmor yet. 
> (Some parts are even hard to understand for me ;-)
> 
> Let me add some comments and proposed additions (marked by +) inline.
> 
>> Cross-distribution topic
>>
>> 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 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.

>> and basic user interaction.
> 
> +  This tool will replace the existing aa-logprof and aa-genprof tools.
> 
> (In other words: the student can try out aa-logprof to get an idea what 
> he's expected to write ;-)
> 
okay

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

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, ...)

> I'd also
> +  Create a tool to merge two profiles into one (working similar 
> +  to logprof, but takes a profile instead of a log as input)
> 
okay

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

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

>> and analyze inter-profile behavior.
> 
> What exactly do you mean with this?
> 
see above

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

>> Required knowledge: basic C, 
> 
> Personally I'd have guessed that C isn't really needed because the 
> existing aa-logprof is perl and the new one is in Python or Go. What did 
> I overlook?
> 
true not needed, just could be useful as the base library and some of
the other components are C

>> Python or Go, 
> 
>> YCP (depenent on implementation route), 
> 
> Which part would require YCP knownledge?
> (or did you forget to mention "update the YaST2 AppArmor module"?)
> 
Well I indirectly mentioned it as a possibility in developing a better
interface. While I would like a more general component I think updating
the YaST interface is a perfectly valid direction if someone wishes to
pursue that route.

>> some knowledge of Perl would be good but is not required
> 
> Well, I'd guess understanding the existing perl code would be good. 
> Or are aa-logprof and AppArmor.pm so bad that people better don't look 
> at them? ;-)
> 
Well they are bad, but being able to look at them wouldn't hurt, also
some of the other tools are in perl as well.

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


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

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: