platform_system_sepolicy/init_shell.te

# Restricted domain for shell processes spawned by init.
# Normally these are shell commands or scripts invoked via sh
# from an init*.rc file.  No service should ever run in this domain.
type init_shell, domain;
domain_auto_trans(init, shell_exec, init_shell)
permissive_or_unconfined(init_shell)

# Run helpers from / or /system without changing domain.
allow init_shell rootfs:file execute_no_trans;
allow init_shell system_file:file execute_no_trans;
Clarify init_shell, shell, and su domain usage. init_shell domain is now only used for shell commands or scripts invoked by init*.rc files, never for an interactive shell. It was being used for console service for a while but console service is now assigned shell domain via seclabel in init.rc. We may want to reconsider the shelldomain rules for init_shell and whether they are still appropriate. shell domain is now used by both adb shell and console service, both of which also run in the shell UID. su domain is now used not only for /system/bin/su but also for adbd and its descendants after an adb root is performed. Change-Id: I502ab98aafab7dafb8920ccaa25e8fde14a8f572 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> 2014-02-21 19:45:29 +01:00			`# Restricted domain for shell processes spawned by init.`
			`# Normally these are shell commands or scripts invoked via sh`
			`# from an init*.rc file. No service should ever run in this domain.`
Refactor the shell domains. Originally we used the shell domain for ADB shell only and the init_shell domain for the console service, both transitioned via automatic domain transitions on sh. So they originally shared a common set of rules. Then init_shell started to be used for sh commands invoked by init.<board>.rc files, and we switched the console service to just use the shell domain via seclabel entry in init.rc. Even most of the sh command instances in init.<board>.rc files have been converted to use explicit seclabel options with more specific domains (one lingering use is touch_fw_update service in init.grouper.rc). The primary purpose of init_shell at this point is just to shed certain permissions from the init domain when init invokes a shell command. And init_shell and shell are quite different in their permission requirements since the former is used now for uid-0 processes spawned by init whereas the latter is used for uid-shell processes spawned by adb or init. Given these differences, drop the shelldomain attribute and take those rules directly into shell.te. init_shell was an unconfined_domain(), so it loses nothing from this change. Also switch init_shell to permissive_or_unconfined() so that we can see its actual denials in the future in userdebug/eng builds. Change-Id: I6e7e45724d1aa3a6bcce8df676857bc8eef568f0 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> 2014-06-11 13:10:09 +02:00			`type init_shell, domain;`
SELinux policy that separates "init_shell" from "shell". "init_shell" is used for shell processes spawned by init. Change-Id: I9e35d485bac91f3d0e4f3704acdbb9af7d617173 2013-05-06 22:24:27 +02:00			`domain_auto_trans(init, shell_exec, init_shell)`
Refactor the shell domains. Originally we used the shell domain for ADB shell only and the init_shell domain for the console service, both transitioned via automatic domain transitions on sh. So they originally shared a common set of rules. Then init_shell started to be used for sh commands invoked by init.<board>.rc files, and we switched the console service to just use the shell domain via seclabel entry in init.rc. Even most of the sh command instances in init.<board>.rc files have been converted to use explicit seclabel options with more specific domains (one lingering use is touch_fw_update service in init.grouper.rc). The primary purpose of init_shell at this point is just to shed certain permissions from the init domain when init invokes a shell command. And init_shell and shell are quite different in their permission requirements since the former is used now for uid-0 processes spawned by init whereas the latter is used for uid-shell processes spawned by adb or init. Given these differences, drop the shelldomain attribute and take those rules directly into shell.te. init_shell was an unconfined_domain(), so it loses nothing from this change. Also switch init_shell to permissive_or_unconfined() so that we can see its actual denials in the future in userdebug/eng builds. Change-Id: I6e7e45724d1aa3a6bcce8df676857bc8eef568f0 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> 2014-06-11 13:10:09 +02:00			`permissive_or_unconfined(init_shell)`
Remove execute_no_trans from unconfineddomain. execute_no_trans controls whether a domain can execve a program without switching to another domain. Exclude this permission from unconfineddomain, add it back to init, init_shell, and recovery for files in / and /system, and to kernel for files in / (to permit execution of init prior to setcon). Prohibit it otherwise for the kernel domain via neverallow. This ensures that if a kernel task attempts to execute a kernel usermodehelper for which no domain transition is defined, the exec will fail. Change-Id: Ie7b2349923672dd4f5faf7c068a6e5994fd0e4e3 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov> 2014-06-19 15:07:17 +02:00
			`# Run helpers from / or /system without changing domain.`
			`allow init_shell rootfs:file execute_no_trans;`
			`allow init_shell system_file:file execute_no_trans;`