- May 09, 2014
-
-
Stephen Smalley authored
This was originally to limit the ability to relabel files to particular types given the ability of all domains to relabelfrom unlabeled files. Since the latter was removed by Ied84f8b4b1a0896c1b9f7d783b7463ce09d4807b, this no longer serves any purpose. Change-Id: Ic41e94437188183f15ed8b3732c6cd5918da3397 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
- Feb 12, 2014
-
-
Stephen Smalley authored
Only allow to domains as required and amend the existing neverallow on block_device:blk_file to replace the exemption for unconfineddomain with an explicit whitelist. The neverallow does not check other device types as specific ones may need to be writable by device-specific domains. Change-Id: I0f2f1f565e886ae110a719a08aa3a1e7e9f23e8c Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
Stephen Smalley authored
Remove sys_ptrace and add a neverallow for it. Remove sys_rawio and mknod, explicitly allow to kernel, init, and recovery, and add a neverallow for them. Remove sys_module. It can be added back where appropriate in device policy if using a modular kernel. No neverallow since it is device specific. Change-Id: I1a7971db8d247fd53a8f9392de9e46250e91f89b Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
- Feb 11, 2014
-
-
Stephen Smalley authored
Only allow to specific domains as required, and add a neverallow to prevent allowing it to other domains not explicitly whitelisted. sdcard_type is exempted from the neverallow since more domains require the ability to mount it, including device-specific domains. Change-Id: Ia6476d1c877f5ead250749fb12bff863be5e9f27 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
- Jan 27, 2014
-
-
Nick Kralevich authored
Require all domain transitions or dyntransitions to be explicitly specified in SELinux policy. healthd: Remove healthd_exec / init_daemon_domain(). Healthd lives on the rootfs and has no unique file type. It should be treated consistent with other similar domains. Change-Id: Ief3c1167379cfb5383073fa33c9a95710a883b29
-
- Jan 08, 2014
-
-
Stephen Smalley authored
Now that we set /sys/fs/selinux/checkreqprot via init.rc, restrict the ability to set it to only the kernel domain. Change-Id: I975061fd0e69c158db9bdb23e6ba77948e3fead1 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
- Dec 06, 2013
-
-
Stephen Smalley authored
As per the discussion in: https://android-review.googlesource.com/#/c/71184/ init sets the enforcing mode in its code prior to switching to the init domain via a setcon command in the init.rc file. Hence, the setenforce permission is checked while still running in the kernel domain. Further, as init has no reason to ever set the enforcing mode again, we do not need to allow setenforce to the init domain and this prevents reverting to permissive mode via an errant write by init later. We could technically dontaudit the kernel setenforce access instead since the first call to setenforce happens while still permissive (and thus we never need to allow it in policy) but we allow it to more accurately represent what is possible. Change-Id: I70b5e6d8c99e0566145b9c8df863cc8a34019284 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
Nick Kralevich authored
The build is broken. Reverting temporarily to fix breakage. libsepol.check_assertion_helper: neverallow on line 4758 violated by allow init kernel:security { setenforce }; Error while expanding policy make: *** [out/target/product/mako/obj/ETC/sepolicy_intermediates/sepolicy] Error 1 make: *** Waiting for unfinished jobs.... This reverts commit bf12e225. Change-Id: I78a05756d8ce3c7d06e1d9d27e6135f4b352bb85
-
Stephen Smalley authored
As per the discussion in: https://android-review.googlesource.com/#/c/71184/ init sets the enforcing mode in its code prior to switching to the init domain via a setcon command in the init.rc file. Hence, the setenforce permission is checked while still running in the kernel domain. Further, as init has no reason to ever set the enforcing mode again, we do not need to allow setenforce to the init domain and this prevents reverting to permissive mode via an errant write by init later. We could technically dontaudit the kernel setenforce access instead since the first call to setenforce happens while still permissive (and thus we never need to allow it in policy) but we allow it to more accurately represent what is possible. Change-Id: I617876c479666a03167b8fce270c82a8d45c7cc6 Signed-off-by:
Stephen Smalley <sds@tycho.nsa.gov>
-
- Nov 08, 2013
-
-
Nick Kralevich authored
Start running in enforcing mode for kernel / init. This should be mostly a no-op, as the kernel / init is in the unconfined domain. Change-Id: I8273d936c9a4eecb50b78ae93490a4dd52f59eb6
-
- Sep 05, 2013
-
-
Geremy Condra authored
For additional context- The denials related to init_tmpfs are of the form: denied { read } for pid=12315 comm=""dboxed_process0"" path=2F6465762F6173686D656D2F64616C76696B2D68656170202864656C6574656429 dev=""tmpfs"" ino=9464 scontext=u:r:isolated_app:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file (the path above is "/dev/ashmem/dalvik-heap (deleted)") The denials related to executing things from the dalvik cache are of the form: enied { execute } for pid=3565 comm=""dboxed_process0"" path=""/data/dalvik-cache/system@app@Chrome.apk@classes.dex"" dev=""mmcblk0p28"" ino=105983 scontext=u:r:isolated_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file The denials related to isolated_app and the init socket are: denied { getattr } for pid=3824 comm=""Binder_2"" path=""socket:[14059]"" dev=""sockfs"" ino=14059 scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket The getopt denials for the aforementioned socket are: denied { getopt } for pid=3824 comm=""Binder_2"" path=""/dev/socket/dumpstate"" scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket Change-Id: I3c57702e2af5a779a7618da9aa40930e7f12ee49
-
- Jul 11, 2013
-
-
Nick Kralevich authored
For unlabeled files, revert to DAC rules. This is for backwards compatibility, as files created before SELinux was in place may not be properly labeled. Over time, the number of unlabeled files will decrease, and we can (hopefully) remove this rule in the future. To prevent inadvertantly introducing the "relabelto" permission, add a neverallow domain, and add apps which have a legitimate need to relabel to this domain. Bug: 9777552 Change-Id: I71b0ff8abd4925432062007c45b5be85f6f70a88
-
- May 15, 2013
-
-
repo sync authored
Bug: 4070557 Change-Id: I027f76cff6df90e9909711cb81fbd17db95233c1
-
- Jan 04, 2012
-
-
Stephen Smalley authored
-