Re: modprobe in kernel context
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.
Re: modprobe in kernel context
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.
Re: modprobe in kernel context
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 stephen.smal...@gmail.com
mailto:stephen.smal...@gmail.com 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
william.c.robe...@intel.com mailto:william.c.robe...@intel.com
wrote:
-Original Message-
From: Stephen Smalley [mailto:stephen.smal...@gmail.com
mailto:stephen.smal...@gmail.com]
Sent: Tuesday, July 21, 2015 11:15 AM
To: Roberts, William C
Cc: seandroid-list@tycho.nsa.gov
mailto: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
mailto: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/
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
Seandroid-list@tycho.nsa.gov mailto:Seandroid-list@tycho.nsa.gov
To unsubscribe, send email
Re: modprobe in kernel context
On Jul 22, 2015 6:12 AM, Stephen Smalley 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.
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 stephen.smal...@gmail.com
mailto:stephen.smal...@gmail.com 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
william.c.robe...@intel.com mailto:william.c.robe...@intel.com
wrote:
-Original Message-
From: Stephen Smalley [mailto:stephen.smal...@gmail.com
mailto:stephen.smal...@gmail.com]
Sent: Tuesday, July 21, 2015 11:15 AM
To: Roberts, William C
Cc: seandroid-list@tycho.nsa.gov
mailto: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
mailto: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
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.
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.
Re: modprobe in kernel context
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.
RE: modprobe in kernel context
-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.
