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.

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).

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.

We don't want anything other than kernel threads running in the kernel
domain.

> 
> On Jul 21, 2015 3:07 PM, "Stephen Smalley" <[email protected]
> <mailto:[email protected]>> wrote:
> 
>     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
>     <[email protected] <mailto:[email protected]>>
>     wrote:
>     >
>     >
>     >> -----Original Message-----
>     >> From: Stephen Smalley [mailto:[email protected]
>     <mailto:[email protected]>]
>     >> Sent: Tuesday, July 21, 2015 11:15 AM
>     >> To: Roberts, William C
>     >> Cc: [email protected]
>     <mailto:[email protected]>
>     >> 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
>     >> <[email protected]
>     <mailto:[email protected]>> 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/
>     <http://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
>     >> > [email protected] <mailto:[email protected]>
>     >> > To unsubscribe, send email to
>     [email protected]
>     <mailto:[email protected]>.
>     >> > To get help, send an email containing "help" to
>     >> > [email protected]
>     <mailto:[email protected]>.
>     _______________________________________________
>     Seandroid-list mailing list
>     [email protected] <mailto:[email protected]>
>     To unsubscribe, send email to [email protected]
>     <mailto:[email protected]>.
>     To get help, send an email containing "help" to
>     [email protected]
>     <mailto:[email protected]>.
> 
> 
> 
> _______________________________________________
> Seandroid-list mailing list
> [email protected]
> To unsubscribe, send email to [email protected].
> To get help, send an email containing "help" to 
> [email protected].
> 

_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to 
[email protected].

Reply via email to