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.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds