On Jul 22, 2015 6:12 AM, "Stephen Smalley" <[email protected]> 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.
>
> 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.
>
> >
> > 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