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>
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 bf12e22514.
Change-Id: I78a05756d8ce3c7d06e1d9d27e6135f4b352bb85
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>
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
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
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
