On 12/04/2016 01:29 PM, Nick Kralevich wrote: > 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? I agree that #2 is preferable, and I believe that is in fact the behavior after commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46 circa Linux 4.8. Easiest way to check is to add auditallow statements to see what execute checks are being applied on a given domain transition. The SELinux support for domain transitions was implemented by hooking the existing functions for setuid/setgid program execution, so there are some suboptimal aspects of the current checking, not only this particular issue but also the label in which the descriptor for the interpreter is opened, which requires the new domain to be able to use descriptors with its parent's label even if not passing any descriptors opened by the parent. Also execute_no_trans is rather imprecise; it only gets checked upon execve(), so a userspace program loader can avoid it entirely and only requires execute permission. _______________________________________________ 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.
