On 04/25/2016 09:25 PM, Stephen Smalley wrote: > On 04/25/2016 02:17 PM, Stephen Smalley wrote: >> On 04/22/2016 08:14 PM, Jeffrey Vander Stoep wrote: >>> AOSP now provides a quick start guide for writing policy for new >>> devices! Please take a look. I've had a couple of selinux newbs run >>> through it during device bringup with good results (and helpful >>> feedback). Your feedback is appreciated. >>> >>> http://source.android.com/security/selinux/device-policy.html >> There is some overlap with >> http://source.android.com/security/selinux/implement.html; not sure if >> you want to unify them. >> >> Services also often require file_contexts entries for their sockets and >> any /data directories they manage, and may require type transitions if >> they dynamically create those files themselves at runtime. >> >> There may be /proc and /sys files that are truly device-specific or that >> only need to be accessed by a device-specific service and therefore >> justify using device-specific types. >> >> Filesystems that do not support labeling can be assigned a default type >> via genfs_contexts, and overridden on per-mount basis via context= mounts. >> >> Often the need for capabilities (not just dac_override but also others >> like chown, fowner, ..) can be avoided by adding a group to the service, >> changing the owner or mode of a file, or pre-creating directories with >> the correct owner/mode in the init.<board>.rc file (rather than in the >> daemon code). >> >> Also, a dac_override denial may only truly require dac_read_search if >> the process only needs read/search permissions and not write; the kernel >> always checks dac_override first and only falls back to checking >> dac_read_search if dac_override was denied and the access is read/search. >> >> We should encourage them to rewrite any audit2allow-generated rules to >> use the policy macros (global_macros, te_macros). Slide 42 of [1] >> >> [1] >> http://events.linuxfoundation.org/sites/events/files/slides/abs2014_seforandroid_smalley.pdf > Bill Roberts had a start at a script to automate translation of > audit2allow output to use policy macros, > https://bitbucket.org/billcroberts/fixup > but it hasn't been kept up to date. > > It may make sense to create an AOSP audit2allow wrapper or similar that > does this automatically. I guess this is a good moment to plug our new tool, SELint [0], which does exactly that (among other things): given a list of policy source files it can suggest using global_macros and te_macros where applicable.
It is still in heavy development, but the functionality is mostly there. We are working closely with Bill Roberts; the tool is developed in the Secure Systems Group at Aalto University under the Intel Collaborative Research Institute for Secure Computing. We will make the first official release of the tool towards the end of may, but the tool can already be tested in its current rough state. If you are interested in trying out the pre-release tool, please check out the "devel" branch of the repository [0]. You can find requirements, installation instructions and usage instructions in the README. Please let us know if you experience any difficulties or crashes while running the tool. Regards, Filippo Bonazzi [0] https://github.com/seandroid-analytics/selint/tree/devel > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
