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] -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
