Here is the avc which I got:
avc: denied { module_request } for pid=844 comm="dex2oat" kmod="personality-8"
scontext=u:r:dex2oat:s0 tcontext=u:r:kernel:s0 tclass=system permissive=0
Here the kmod=personality-8
This is just one avc , there are many such avc for personality-8 which I get. I
am using kernel-3.10.
But with http://marc.info/?l=linux-arch&m=142912798314177&w=2 it seems that
they have removed the support of exec domains.
Thanks.
-----Original Message-----
From: Stephen Smalley [mailto:s...@tycho.nsa.gov]
Sent: Friday, September 11, 2015 6:06 PM
To: Inamdar Sharif; Roberts, William C; seandroid-list@tycho.nsa.gov
Subject: Re: kernel module request personality-8
On 09/11/2015 02:53 AM, Inamdar Sharif wrote:
> Thanks.
>
> This really helps a lot. I can see a lot many domains ask for
> module_request permissions.
You don't necessarily want to dontaudit all such cases; this specific case was
for the legacy execution domains feature and there was no module by that name
to load, so there was no reason to allow it. Some module_request cases may be
legitimate and may need to be allowed, e.g.
to load a device driver on demand. You need to look at the kmod= value and see
whether such a module exists and can be legitimately loaded as a result of the
normal actions of that process (e.g. loading of network modules in response to
using network sockets).
The difference between module_request and sys_module is that the former is
checked when the kernel tries to auto-load a module in response to some system
call, whereas the latter is checked when userspace tries to load a (potentially
arbitrary) module. Allowing module_request is less of a risk since the process
has less control over what is loaded, but there have been cases where it has
been abused to load a known-vulnerable driver that can then be exploited, or to
trigger an attempted load of a non-existent module just to get an
attacker-supplied modprobe to run with full permissions. That's why SELinux
has a module_request permission check these days.
Of course, none of this is needed if you have CONFIG_MODULES=n, which is
preferred for Android.
>
>
>
> *From:*Seandroid-list [mailto:seandroid-list-boun...@tycho.nsa.gov]
> *On Behalf Of *Roberts, William C
> *Sent:* Thursday, September 10, 2015 10:35 PM
> *To:* seandroid-list@tycho.nsa.gov
> *Subject:* kernel module request personality-8
>
>
>
> This email serves a public record for anyone else wondering what to do
> with these audits.
>
>
>
> Recently when working on Android with a 3.14.37 kernel, I came across
> the following audits:
>
>
>
> [ 170.456077] type=1400 audit(1432616225.277:76): avc: denied {
>
> module_request } for pid=3742 comm="debuggerd" kmod="personality-8"
>
> scontext=u:r:debuggerd:s0 tcontext=u:r:kernel:s0 tclass=system
>
> permissive=1
>
>
>
> $ adb shell ps -Z | grep debuggerd
>
> u:r:debuggerd:s0 root 3742 1 /system/bin/debuggerd
>
> u:r:debuggerd:s0 root 3743 1 /system/bin/debuggerd64
>
>
>
> I saw these for pretty much any 32 variant of an executable. I was
> also on an intel x86 Android platform, I am not sure if this will
>
> Be relevant to other arch's or not. I was able to safely "dontaudit"
> this, and it seems removed from 4.0 kernels. Stephen (paraphrasing
> the
> email) provided
>
> The following informative links as well as suggesting a dontaudit:
>
>
>
> http://marc.info/?l=linux-kernel&m=128934356223514&w=2
>
>
>
> More context:
>
> http://marc.info/?l=linux-kernel&m=142878569719810&w=2
>
>
>
> Looks like it got removed entirely in 4.0:
>
> http://marc.info/?l=linux-arch&m=142912798314177&w=2
>
>
>
> Hopefully this helps some lost soul in the future.
>
>
>
>
>
> ----------------------------------------------------------------------
> -- This email message is for the sole use of the intended recipient(s)
> and may contain confidential information. Any unauthorized review,
> use, disclosure or distribution is prohibited. If you are not the
> intended recipient, please contact the sender by reply email and
> destroy all copies of the original message.
> ----------------------------------------------------------------------
> --
>
>
> _______________________________________________
> 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.
