Tooling and High level APIs

Enhance sepolicy-analyze to perform more complex forms of analysis, including identifying isomorphic domains/types to help identify candidates for merging beyond the current typecmp module.

Improve audit2allow or create an Android-specific variant that uses the Android policy macros where possible (ala audit2allow -R in Linux), to provide improved assistance with MLS denials, and to possibly suggest/automate generating new domains/types.

Middleware/Userspace Policy Enforcement

Identify further Android components that would benefit from being extended to be SELinux userspace object managers, i.e. apply SELinux permission checks over their userspace objects and operations in addition to or instead of any existing DAC-based controls. Some possible candidates include vold and logd. Thus far this has been done for the init property service, zygote, servicemanager, keystore, debuggerd, and drmserver; the relevant code is available in AOSP. Socket-based services can use getpeercon() or SCM_SECURITY to get the source/subject context. Binder-based services can use getpidcon() on the binder calling PID to get the source/subject context. The target/object context can be looked up from a contexts configuration (as in the init property service or servicemanager), a context of an actual target/object (as in debuggerd), or just always the context of the server process (as in the keystore and drmserver).

Augment or replace all hardcoded checks of the root or system UID in Android with SELinux permission checks so that we can restrict access to specific domains rather than to all processes that have that UID (or any process that has CAP_SETUID).

Userspace Labeling Support

Augment vold or other appropriate components to ensure that the labels assigned to devicemapper device nodes are computed from the label of the underlying device node, so that access to the dm device nodes can be controlled consistently, e.g. when using encrypted storage. http://marc.info/?t=144416109500001&r=1&w=2

Policy Improvements

Investigate what rules in domain.te and app.te should and can be removed and only added back to those specific processes that need them. An example goal is to minimize the permissions inherited by domains such as isolated_app, used by the Chrome sandbox, or to permit creation of new sandboxed domains.

Introduce a separate type for /data directories that should be writable by system UID apps such as /data/system/cache and /data/misc/keychain and assign it via type_transition and/or file_contexts entries. See if we can remove write access to system_data_file from system_app. If not, at least introduce a separate type for critical /data/system files that should only be writable by the system_server if we can preserve those labels across updates.

Split app data file types from types used on other /data directories so that we can distinguish them in policy and don't have to allow access to /data subdirectories just because we have to allow access to app files (or vice versa).

Remove sysfs:file write access from various domains, replacing with specific sysfs types only for the files they need to write.

Review the capabilities presently allowed to the system_server and see whether we can remove some of them without breaking functionality. Presently we allow all of the capabilities that are assigned to the system_server by the zygote when it is started, but it is unclear whether all of them are truly required.

Transition helper programs executed by various privileged domains into their own, less privileged domain, so that a vulnerability in the helper program, particularly when accessing untrusted input, cannot exercise the full privileges of the caller. See for example the init domain, which is not allowed to execute any other programs without transitioning to another domain, and the installd domain, which transitions to separate domains when executing dex2oat or idmap.

Address various TODO or XXX comments in files under external/sepolicy.

Review and work to eliminate all auditallow rules in policy; these usually indicate some case where we are not sure if the permission is still required or we would like to remove the need for the permission through a change to the relevant code.

Maybe tighten the binder policy. Presently we assign the binderservicedomain attribute to most daemon domains that implement a binder service via the binder_service() macro and then allow various domains to call any one of them via binder_call(..., binderservicedomain). We also allow any app domain to call any other app domain via binder_call(appdomain, appdomain). If it makes sense to do so (i.e. there are specific cases we truly want to block), then migrate this to more of a least privilege policy. We may however be getting adequate coverage through the separate service_manager find permission check, which restricts the ability to lookup binder references for service names registered with the servicemanager, although this does not cover any binder references obtained via other means.

Maybe switch from using file_contexts and restorecon_recursive to label /sys to using genfs_contexts instead. Need to evaluate the tradeoffs of the different approaches. Depends on this change finding its way into all device kernels: https://android-review.googlesource.com/#/c/151776/

Testing

Extend the domain tests in SELinuxHostTest to also test some app domain assignments. For example, we can test that no app that has a UID other than system is running in the system_app domain, and likewise for blutooth, nfc, radio and shell. Testing the reverse constraint (i.e. that every app that has the system UID runs in the system_app domain) may be too strict since an OEM could place a specific system UID app into its own domain via additional mac_permissions.xml and/or seapp_contexts entries. Validating that platform_app is only assigned to apps signed by platform certificate may be harder, would require getting app seinfo value for running apps in some manner, either by reading packages.list or by reading mac_permissions.xml and computing (requires getting certificates for running apps) or by asking PMS for it in some way.

Add new SELinuxHostTest tests to pull and validate /system/etc/security/mac_permissions.xml against common errors. Get our tools for mac_permissions.xml into AOSP and use for validation.

Investigate approaches to reducing need for / eliminating memory regions and files that can be both written and executed by apps. Analyze ART to see if helps in any way by doing ahead-of-time compilation. In current policy, we allow execmem permission (add PROT_EXEC to anonymous or writable private file mappings, used for Dalvik JIT mapping, might not be needed with ART?), execute to ashmem_device (add PROT_EXEC to mappings from /dev/ashmem, ditto), execute to gpu_device (add PROT_EXEC to mappings from the gpu driver, seemingly used by openGL?), execute to app_data_file (map native code shared libraries packaged as assets with PROT_EXEC, wouldn't be required if they were packaged in the officially supported way instead), and execute_no_trans to app_data_file (execute binaries packaged as assets, e.g. busybox). See also "Execute This! Analyzing Unsafe and Malicious Dynamic Code Loading in Android Applications" for some related discussion of dynamic code loading vulnerabilities in Android. This change, https://android-review.googlesource.com/#/c/98944/, is intended to let us see what still requires execmem and ashmem PROT_EXEC now that ART has replaced Dalvik.

Study Android multi-user support, assess its suitability for isolation, improve it where needed. See "A Systematic Security Evaluation of Android's Multi-User Framework" for some background.

SELinux Kernel Improvements

Extend FUSE to pass up the client process security context for use by the sdcard daemon as a userspace object manager? Alternatively (or in the near term), sdcard could just use getpidcon() as we have done for Binder-based services.

Extend SELinux /proc/pid labeling support to support derived types on specific /proc/pid files based on both the associated task context and the file name, e.g. name-based type transitions. This would allow applying different restrictions to different /proc/pid files of the same process via SELinux.

Generalize the current hardcoded tests of specific filesystem type names used to determine whether to support setting per-file security contexts via setxattr on a genfscon-labeled filesystem and whether to initially label the files from policy based on pathname from the root of the filesystem. The former is only safe if the filesystem either implements its own setxattr handler for security labels or the filesystem pins its inodes in memory, as otherwise the label may not be preserved for the lifetime of the file. The latter is only safe if the filesystem does not permit userspace to modify the directory tree (i.e. no .create/.link/.rename methods or filesystem is not mountable by userspace), as otherwise userspace can potentially cause files to move in and out of a given label or to be accessible under different labels depending on which path is first looked up. We currently permit the former for sysfs (implements its own handler that saves/restores the value when the inode is evicted and later re-created from a backing data structure), and for pstore, debugfs, and rootfs (all of which pin their inodes in memory). We currently permit the latter for debugfs, sysfs, and pstore, as the first two do not permit any userspace manipulation of directories and the latter only permits unlink, which causes no issues by itself. We either need some way to detect which filesystems are safe to use in the kernel or specify the whitelists of filesystem type names in the policy.