On Wed, Jul 22, 2015 at 8:02 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote:
> 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. > Yep that just dawned on me and was getting ready to say that won't work. -- Respectfully, William C Roberts
_______________________________________________ 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.
