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 _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
