On 07/22/2015 10:50 AM, William Roberts wrote: > > On Jul 22, 2015 6:12 AM, "Stephen Smalley" <s...@tycho.nsa.gov > <mailto:s...@tycho.nsa.gov>> wrote: >> >> On 07/21/2015 07:26 PM, William Roberts wrote: >> > But you can't label sbin currently so I could set up a transition but >> > then all usermode helpers would end up in that domain, not sure if that >> > really buys me anything beyond leaving it in kernel. >> > >> > I could setup a oneshot service and have the usermode helpers setprop >> > ctl.start name but making it synchronous to asynchronous seems like a >> > bad idea. >> >> So, first CONFIG_MODULES=y is frowned upon in Android AFAIK; they even >> tried having a CTS test to prohibit it at one point. Just another >> vector for code injection into the kernel. > > Unfortunately I cannot change this anytime soon. > >> >> Second, you can configure /proc/sys/kernel/modprobe to refer to a >> /system/bin binary just by adding a write /proc/sys/kernel/modprobe >> /system/bin/modprobe to your init.<board>.rc file, so you can easily >> move modprobe to the system partition and label it there. This of course >> presumes that you don't need to load any kernel modules to mount the >> /system partition (e.g. CONFIG_EXT4_FS=y, not = m > > Need it before system is mounted.
To do what? Load the drivers for the block storage and then to load the ext4 filesystem module itself? You can't build those into your kernel? Is this a case of using a single kernel for many different devices with different storage drivers? >> >> Or you could apply your patches for applying restorecon to /sbin and >> assign /sbin/modprobe a label that way. This presumes that you don't >> need to autoload any modules prior to that restorecon call. > > I don't want to merge anything not merged on master > >> >> We don't want anything other than kernel threads running in the kernel >> domain. > > Sure but all I would have right now is one gigantic privileged domain > for all usermode helpers that I can't possibly ensure work across all > targets in one shot, thus labeling and moving one at a time (ie apply my > patches) is the only realistic way of doing this. Yes, if you cannot label the executable (either by moving it to /system or by adding the rootfs restorecon support), then you don't really have any options other than running it in the kernel domain and adding any required permissions to that domain. You can't do an automatic domain transition on rootfs without also affecting the initial exec of init. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
