| |||||||||||||
The AppArmor debate beginsThe AppArmor debate beginsPosted Apr 27, 2006 6:56 UTC (Thu) by nix (subscriber, #2304)In reply to: The AppArmor debate begins by jamesm Parent article: The AppArmor debate begins
This is the *point* of the learning system. The idea is that you run your target app in learning mode while it is *not* being attacked (which basically runs it with everything banned, but with the system set to log, not deny failed operations, and then analyzes the logfile). The resulting policy will only allow the target app to do what it did while you were running it in learning mode, which may include... unexpected things.
If you want to know *why* those unexpected things are being done, you'll have to examine the app's source code: and oddly enough Crispin didn't want to do that for a monster like Thunderbird.
This is (yet another place) where *exactly* the same criticism can be made of SELinux, except that of course because it doesn't have a learning mode you'll have to do the log analysis yourself.
(Log in to post comments)
The AppArmor debate begins Posted Apr 27, 2006 8:58 UTC (Thu) by james (subscriber, #1325) [Link] audit2allow is a "learning mode" for SELinux -- it takes the audited failures and creates rules to allow them.
audit2allow: more details Posted Apr 27, 2006 17:10 UTC (Thu) by bkoz (guest, #4027) [Link]
Thanks.
Huh. Interesting. This tool looks quite useful.
I found more details here:
Is there other documentation about this? (Targeted at non-studly sys admin types such as myself?)
audit2allow: more details Posted Apr 27, 2006 19:36 UTC (Thu) by jamesm (guest, #2273) [Link] Try the SELinux wiki: http://fedoraproject.org/wiki/SELinux Dan Walsh's blog: http://danwalsh.livejournal.com/ There's also a comprehensive book coming out, soon.
The AppArmor debate begins Posted Apr 27, 2006 13:10 UTC (Thu) by jamesm (guest, #2273) [Link] The exact same criticism cannot be made, as this is not the primary way that policy is developed under SELinux (it comes with the apps). You can use audit2allow, but I would not recommend it as anything but an adjunct to designing policy and then only if you understand what it's doing. (I know that it's mentioned in a lot of the online documentation -- possibly without enough caveats). I was discussing something similar to a learning mode for SELinux with another developer last year at OLS, and it can definitely be done, say, with per-process permissive mode. I don't think it's the right approach alone, but could be useful when used by a trained policy developer with some other features such as static analysis of the source code, peeking inside RPMs etc. There are tools now being developed for SELinux which operate at a higher level, with a wizard-like interface which allows security goals to be defined by the user, from which a security policy is generated.
The AppArmor debate begins Posted May 1, 2006 16:04 UTC (Mon) by Method (guest, #26150) [Link] Congratulations, you identified the precise problem with this type of system. For comparison the SELinux Thunderbird policy *does not* include this capability, proof positive that iterative active policy development will yeild higher quality policies than 'status quo encapsulation'. If thunderbird functions properly without this permission then it should not be there.
See http://securityblog.org/brindle/2006/03/25/security-anti-...
The point mentioned in your post about using learning mode while the app is not being attacked is talked about in the above article but I'll refute it here incase people don't want to read it. Once your system is active (eg., thunderbird is fetching mail from your server) it is no longer in a known good state, you have no idea if it is being attacked or otherwise compromised. The fact that blindly writing policies in this manner can actually create channels for the attackers to operate on after the policy is active is disturbing and IMHO a very compelling argument against this type of behavior.
|
|||||||||||||