[apparmor] [Branch ~kgupta8592/apparmor-profile-tools/trunk] Rev 7: added severity.py with tested convert_regex and the old and new config
apparmor at cboltz.de
Tue Jun 18 22:34:48 UTC 2013
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.
the configfile (inside the test directory)
a configparser object, with
- [foo] bar == xy
- [foo] xy not set
> 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]
More information about the AppArmor