really for any device. It's not meant to be a Q&A but as an evolving source of reference. The approach
towards the gathering of the information will be in a pick and pack format. Anyone who's ever worked in a warehouse
will know how that is.
Skipping through rationale, selling points, and philosophy, here is the first bit of info i've been wanting to know for a while. And maybe will help with cm11.
from this site - http://events.linuxfoundation.org/si...id_smalley.pdf
Each process and object is labeled with a security context.
A string of the form user:role:type:level.
Only the type field is used in AOSP presently.
Process types are also called domains.
Domains and types are security equivalence classes.
Identifiers for processes and objects in policy.
Same domain/type => same access.
The security policy configuration defines:
how to label processes and objects with domains and types,
how domains can interact with each other (e.g. signals, IPC, ptrace), and how domains can access types.
No processes are exempt from the policy.
Not overridden by uid-0 or Linux capabilities.
Only notion of unconfined is policy-defined.
SELinux Possible States
Disabled=Not enabled in the kernel or disabled via kernel parameter.
Permissive=Just logs denials but does not enforce them.
Enforcing=Logs and enforces denials for all enforcing domains (processes).
Permissive for specific domains (processes).
Specified in policy on a per-domain basis.
Enables incremental application of SELinux to an ever increasing portion of the system.
Enables policy development for new services and apps while keeping the rest of the system enforcing.