Scenerio:
1) Process P is running in the "P" SELinux domain.
2) A type transition is defined such that when P executes Q_exec, P transitions into SELinux domain Q.
3) Q_exec is an ELF executable with an INTERP (dynamic linker) header pointing to a file labeled R_interp_lib
4) Domain P has file execute permission on R_interp_lib and Q_exec. P does NOT have execute_no_trans on Q_exec nor on R_interp_lib.
5) Domain Q has file execute permissions on Q_exec, but does NOT have file execute permissions on R_interp_lib.
6) P executes Q_exec
What is the intended behavior? Is it:
1) P can successfully execute Q_exec. The process in domain Q has R_interp_lib mapped into the process as executable memory even though it wasn't explicitly allowed by policy. This was allowed because P has execute on R_interp_lib.
2) P gets "permission denied" attempting to run Q_exec, because the resulting domain Q does not have execute permission on R_interp_lib, and Q needs R_interp_lib to successfully run.
Other?
From my (admittedly weak) understanding of the current kernel code today, it appears the answer is #1. The permission checks performed by the kernel when loading the dynamic linker occur in the initiating SELinux domain, not the resulting SELinux domain. So as long as the executing process has execute on the dynamic linker, the target process will have the dynamic linker mapped into it's memory.
Intuitively, I would have expected #2. In the same way that a process shouldn't be able to be executed it doesn't have file execute on it's own executable, it shouldn't be able to be executed if it doesn't have execute on it's dynamic linker.
Thoughts?
--
Nick Kralevich | Android Security | nnk@xxxxxxxxxx | 650.214.4037
_______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
