[apparmor] [Branch ~kgupta8592/apparmor-profile-tools/trunk] Rev 7: added severity.py with tested convert_regex and the old and new config

[Christian Boltz]

Hello,

Am Dienstag, 18. Juni 2013 schrieb Kshitij Gupta:
> On Tue, Jun 18, 2013 at 6:34 PM, Christian Boltz wrote:
> > (with >34 °C outside, I decided to spend some hours in the office
> > ;-)
> 
> You seem to be having a pretty hot summer, apparently that works in my
> favour today. :-)

Well, I'm not sure yet if we can call it summer - it was quite cold for 
a long time ;-) Today was the second "hot" day (up to 37 °C).

> > === lib/config.py ===

> > From users' POV, it might be better to keep the previous permissions
> > instead of using hardcoded 600 - but 600 is more secure.
> > @John: what is your opinion about this?
> 
> For old files, we can skip setting the permissions, while owner
> read/write seems fairly okay to me for new files, but then I might be
> completely missing out on some scenario. ;-)

Well, if you implement the "write tempfile, then replace original file" 
method, you won't have something like "old files" ;-) - you'll need 
something like "chown --reference $file" and "chmod --reference $file"

> > === severity.py ===

> > The "SD_" prefix probably dates back to the times when AppArmor was
> > named "SubDomain". Feel free to use another prefix, maybe "AA_" ;-)
> 
> I was actually beginning to wonder where did all SD's come from,
> thanks for clearing that. That's why its necessary to know about
> history ;-)

;-)

> >>     def convert_regexp(self, path):
> >> [...]
> >>         regex = regex.replace('SDPROF_INTERNAL_GLOB', '*')
> > 
> > I might be paranoid, but - what happens if access to a file called
> > /foo/barSDPROF_INTERNAL_GLOB is requested? ;-)
> > This is highly theoretical for severity.db, but please keep it in
> > mind if you use similar code for logprof/genprof. (You probably
> > won't be able to avoid such conflicts, but you can reduce their
> > chance by choosing a longer/more "cryptical" string.)
> 
> I had a good laugh at that. ;-)
> I tested the code against severity.db for any anomalies and felt that
> was sufficient.
> If ever such a bug did arise, I believe it would be very hard to
> trace. Now I see how you got all those bug-reports. :-)

Let me quote from http://php.net/manual/en/security.general.php

    The input you may expect will be completely unrelated to the input 
    given by a disgruntled employee, a cracker with months of time on 
    their hands, or a housecat walking across the keyboard. 

;-)

> "Cryptic"? Any weird things you'd want inserted? ;-)

See above - let your housecat walk across the keyboard ;-)

Something like __YSDRFTZUIOLKJBVCXSWER_internal_glob_POIUZTRFEDWQEDFGH__ 
should really be good enough - and, as a side effect, my keyboard is 
free of dust now ;-)

Needless to say that you should store this in a constant to avoid 
typos ;-)  (Don't use random values that are generated at runtime 
because this would make debugging impossible.)

> > === configbkp.py ===
> > 
> > Looks like a copy of the old code in config.py. That's why bzr has a
> > version history - no need to checkin backups of old code ;-)
> 
> Actually I have the backup module to be able to compare the results
> with the new module. Assuming, the previous one worked.

Sounds like a good idea for writing the first testcase.

Input: 
the configfile (inside the test directory)

expected results:
a configparser object, with
- [foo] bar == xy
- [foo] xy   not set
etc.


Regards,

Christian Boltz
-- 
[LPIC-1-"Schein"]
> Mir ist egal ob du ihn jetzt HAST, ich will, daß derjenige es KANN.
Bist du Ausländer?  :)
In Deutschland ist es doch so, du muss nix können. Du musst nur ein 
Papier haben wo drauf steht das du was kannst.
[> Peer Heinlein und Roland M. Kruggel in postfixbuch-users]