On 04/22/2014 09:18 PM, Jaejyn Shin wrote: > Dear SEAndroid developers. > > I found following unconfined domains in the aosp mater source. > > init_shell.te:6:unconfined_domain(init_shell) > init.te:4:unconfined_domain(init) > kernel.te:7:unconfined_domain(kernel) > recovery.te:4:unconfined_domain(recovery) > su.te:16: unconfined_domain(su) -> su is unconfined only in > userdebug_or_eng > > I think that all domain should not be unconfined domain to be more secure. > Is there specific reason to remain those domains as the "unconfined" ?
First, if you look at the changes in AOSP master, you will see that we have been incrementally removing specific permissions from unconfined.te to enforce specific security goals so that unconfined_domain() is no longer truly all powerful. We have simultaneously been removing permissive_or_unconfined() calls from various domains to take them out of unconfined altogether. So you get a situation where the policy is converging toward confinement for both unconfined and confined domains. However, for those specific domains, I don't truly expect them to ever be fully locked down to least privilege. The kernel domain is only for kernel threads (checked by the SELinuxDomainTest CTS test in AOSP master) and kernel-launched usermodehelpers (unless a domain transition is defined for them from the kernel domain). The kernel obviously cannot be truly confined by itself, and the kernel-launched usermodehelpers often require privileges that render them equivalent to the kernel. One thing we have done to help protect the kernel domain is by removing the ability of unconfined domains to execute from /data and by restricting the ability to write to /proc and /sys nodes that configure usermodehelpers, we have blocked the ability of an errant root process to write the path to some malicious program to one of those nodes and trigger their execution in the kernel domain. The init domain is only for init (also checked by CTS in AOSP master), which necessarily has to load policy and set enforcing mode and therefore is already able to do as it wishes wrt SELinux (plus it has to handle initial mounting of filesystems and other highly privileged actions). Also, since the init program executes actions from init*.rc files, we cannot fully predict the complete set of actions it will ever take, making it difficult to lock down to complete least privilege. However, as with the kernel domain, our changes to unconfined.te to protect unconfined domains should help protect init. The recovery domain is only for the recovery program (assigned via seclabel in the recovery init.rc file; SELinuxDomainTest confirms that nothing is running in that domain since it should only exist when booting recovery); it has to be able to mount filesystems and write to partitions to wipe them, so it has to retain that level of access, and it can also be driven by external command files that make it difficult to fully specify a complete least privilege policy for it. The su domain is only included in the build for non-user builds (i.e. -userdebug or -eng), so it is irrelevant for securing user builds (SELinuxDomainTest checks that nothing is running in it, although that doesn't guarantee that it doesn't exist in the policy of course; that should be caught by the SELinuxTest CTS test of the policy rules instead). In non-user builds, it is intentionally unrestricted (both unconfined and permissive) since it can be used to initiate arbitrary commands for development purposes and any policy for it to fully operate would trigger neverallow failures (and we can't exclude it from those because the domain is fully omitted from the -user build policy). The init_shell domain is less well-defined; it is for sh commands executed from init.*.rc files to run some initialization script just so that we can more tightly restrict those scripts than the init program itself (SELinuxDomainTest checks that nothing is running in it as such commands should be transient and not long-running services). It is unconfined but doesn't get the additional permissions granted to the init domain (in init.te), so it isn't all powerful. I wouldn't mind seeing that one get more restricted but it is hard to define the complete set of actions that might ever get performed by such scripts and create a full least privilege policy. We could perhaps remove unconfined_domain() from external/sepolicy/init_shell.te and add specific rules for init_shell to the device-specific policies for devices that execute sh commands from their init.<board>.rc files. But that would require some analysis of exactly what they are doing. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
