The transition is on the exec of whatever program path is specified by /proc/sys/kernel/modprobe (and likewise for the other usermodehelpers - you configure a path via a proc or sysfs or cgroup node, and then the kernel exec's that path). We want domain transitions on any usermodehelper as noted in the comment. The only reason we permit execute_no_trans to rootfs is for the initial exec of init by the kernel, prior to its use of setcon to the init domain.
On Tue, Jul 21, 2015 at 4:19 PM, Roberts, William C <william.c.robe...@intel.com> wrote: > > >> -----Original Message----- >> From: Stephen Smalley [mailto:stephen.smal...@gmail.com] >> Sent: Tuesday, July 21, 2015 11:15 AM >> To: Roberts, William C >> Cc: seandroid-list@tycho.nsa.gov >> Subject: Re: modprobe in kernel context >> >> Most Android kernels are built with CONFIG_MODULES=n these days. Is yours >> built with it enabled? If so, then yes, you need to define a domain >> transition >> from kernel to a new domain on modprobe execution. > > No modules are enabled. Is the transition on exec of usermodehelper > > According to your comment in kernel.te here we should really only define a > transition if the executable > Is outside of the rootfs > > # The kernel domain is never entered via an exec, nor should it > # ever execute a program outside the rootfs without changing to another > domain. > # If you encounter an execute_no_trans denial on the kernel domain, then > # possible causes include: > # - The program is a kernel usermodehelper. In this case, define a domain > # for the program and domain_auto_trans() to it. > # - You failed to setcon u:r:init:s0 in your init.rc and thus your init > # program was left in the kernel domain and is now trying to execute > # some other program. Fix your init.rc file. > # - You are running an exploit which switched to the init task credentials > # and is then trying to exec a shell or other program. You lose! > > >> >> On Mon, Jul 20, 2015 at 6:43 PM, Roberts, William C >> <william.c.robe...@intel.com> wrote: >> > I am getting this message and having a fun time tracking it down. My >> > best guess is that a user mode helper is executing this. >> > >> > >> > >> > <38>[ 29.983923] type=1400 audit(946684830.959:3): avc: denied { >> > sys_module } for pid=236 comm="modprobe" capability=16 >> > scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability >> > permissive=1 >> > >> > >> > >> > # cat /proc/sys/kernel/modprobe >> > >> > /sbin/modprobe >> > >> > >> > >> > # ls -laZ /proc//sys/kernel/modprobe >> > >> > -rw-r--r-- root root u:object_r:usermodehelper:s0 modprobe >> > >> > >> > >> > Should I just label this and set up a domain transition? Our kernel >> > does contain the rootfs patch https://android- >> review.googlesource.com/#/c/58360/. >> > >> > >> > >> > Is this barking down the right path, or should I just give kernel >> > domain this capability? >> > >> > >> > _______________________________________________ >> > 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. _______________________________________________ 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.
