bf12e22514
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>
14 lines
490 B
Text
14 lines
490 B
Text
# init switches to init domain (via init.rc).
|
|
type init, domain;
|
|
# init is unconfined.
|
|
unconfined_domain(init)
|
|
tmpfs_domain(init)
|
|
relabelto_domain(init)
|
|
# add a rule to handle unlabelled mounts
|
|
allow init unlabeled:filesystem mount;
|
|
|
|
allow init {fs_type dev_type file_type}:dir_file_class_set relabelto;
|
|
allow init kernel:security { load_policy setenforce };
|
|
allow init usermodehelper:file rw_file_perms;
|
|
allow init proc_security:file rw_file_perms;
|
|
allow init kernel:security load_policy;
|