* Re: [not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com> @ 2018-11-12 10:09 ` Ravi Kumar 2018-11-15 13:11 ` Re: Ondrej Mosnacek 1 sibling, 0 replies; 4+ messages in thread From: Ravi Kumar @ 2018-11-12 10:09 UTC (permalink / raw) To: selinux <<Sorry re-sending in plan text >> Hi team , On android- with latest kernels 4.14 we are seeing some denials which seem to be very much genuine to be address . Where kernel is trying to kill its own created process ( might be for maintenance) . These are seen in long Stress testing . But I dont see any one adding such rule in general so the question is do we see any risk which made us not to add such rules ? 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 This is self capability any one in kernel context should be able to do such operations I guess. Regards, Ravi ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com> 2018-11-12 10:09 ` Ravi Kumar @ 2018-11-15 13:11 ` Ondrej Mosnacek 2018-11-15 14:42 ` Android kill capability denials Stephen Smalley 1 sibling, 1 reply; 4+ messages in thread From: Ondrej Mosnacek @ 2018-11-15 13:11 UTC (permalink / raw) To: nxp.ravi; +Cc: selinux, Paul Moore, Stephen Smalley, SElinux list On Mon, Nov 12, 2018 at 7:56 AM Ravi Kumar <nxp.ravi@gmail.com> wrote: > Hi team , > > On android- with latest kernels 4.14 we are seeing some denials which seem to be very much genuine to be address . Where kernel is trying to kill its own created process ( might be for maintenance) . > These are seen in long Stress testing . But I dont see any one adding such rule in general so the question is do we see any risk which made us not to add such rules ? > > 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 > > This is self capability any one in kernel context should be able to do such operations I guess. The reference policy does contain a rule that allows this kind of operations, see: https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/kernel/kernel.te#L203 It is also present in the Fedora policy on my system: $ sesearch -A -s kernel_t -t kernel_t -c capability -p kill allow kernel_t kernel_t:capability { audit_control audit_write chown dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill lease linux_immutable mknod net_admin net_bind_service net_broadcast net_raw setfcap setgid setpcap s etuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace sys_rawio sys_resource sys_time sys_tty_config }; Therefore I would say it is perfectly fine to add such rule to your policy as well. Cheers, -- Ondrej Mosnacek <omosnace at redhat dot com> Associate Software Engineer, Security Technologies Red Hat, Inc. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Android kill capability denials 2018-11-15 13:11 ` Re: Ondrej Mosnacek @ 2018-11-15 14:42 ` Stephen Smalley 2018-11-15 15:42 ` Stephen Smalley 0 siblings, 1 reply; 4+ messages in thread From: Stephen Smalley @ 2018-11-15 14:42 UTC (permalink / raw) To: Ondrej Mosnacek, nxp.ravi Cc: selinux, Paul Moore, SElinux list, Nick Kralevich On 11/15/18 8:11 AM, Ondrej Mosnacek wrote: > On Mon, Nov 12, 2018 at 7:56 AM Ravi Kumar <nxp.ravi@gmail.com> wrote: >> Hi team , >> >> On android- with latest kernels 4.14 we are seeing some denials which seem to be very much genuine to be address . Where kernel is trying to kill its own created process ( might be for maintenance) . >> These are seen in long Stress testing . But I dont see any one adding such rule in general so the question is do we see any risk which made us not to add such rules ? >> >> 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 >> 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 >> 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 >> 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability permissive=0 >> >> This is self capability any one in kernel context should be able to do such operations I guess. > > The reference policy does contain a rule that allows this kind of > operations, see: > https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/kernel/kernel.te#L203 > > It is also present in the Fedora policy on my system: > > $ sesearch -A -s kernel_t -t kernel_t -c capability -p kill > allow kernel_t kernel_t:capability { audit_control audit_write chown > dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill > lease linux_immutable mknod net_admin net_bind_service net_broadcast > net_raw setfcap setgid setpcap s > etuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace > sys_rawio sys_resource sys_time sys_tty_config }; > > Therefore I would say it is perfectly fine to add such rule to your > policy as well. Android uses a completely different policy not based on the reference policy at all, and tries to limit even the kernel and init domains to least privilege. There are a few reasons to limit even the kernel domain: 1) To protect kernel threads and kernel usermodehelpers from being tricked into misusing their privileges and ensuring that they always transition to a non-kernel domain upon executing a usermodehelper. 2) To render typical kernel exploits that just switch to the init cred or otherwise rewrite their cred to use SECINITSID_KERNEL from gaining full privileges. There are no unconfined domains in Android policy. I think we would at least want to know why the permission check is occurring, as it might reflect a kernel bug. If you can get system call audit info, then you can see additional information that may be helpful. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Android kill capability denials 2018-11-15 14:42 ` Android kill capability denials Stephen Smalley @ 2018-11-15 15:42 ` Stephen Smalley 0 siblings, 0 replies; 4+ messages in thread From: Stephen Smalley @ 2018-11-15 15:42 UTC (permalink / raw) To: Ondrej Mosnacek, nxp.ravi; +Cc: selinux, SElinux list On 11/15/18 9:42 AM, Stephen Smalley wrote: > On 11/15/18 8:11 AM, Ondrej Mosnacek wrote: >> On Mon, Nov 12, 2018 at 7:56 AM Ravi Kumar <nxp.ravi@gmail.com> wrote: >>> Hi team , >>> >>> On android- with latest kernels 4.14 we are seeing some denials >>> which seem to be very much genuine to be address . Where kernel is >>> trying to kill its own created process ( might be for maintenance) . >>> These are seen in long Stress testing . But I dont see any one >>> adding such rule in general so the question is do we see any risk >>> which made us not to add such rules ? >>> >>> 1. avc: denied { kill } for pid=2432 comm="irq/66-90b6300." >>> capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 >>> tclass=capability permissive=0 >>> 2. avc: denied { kill } for pid=69 comm="rcuop/6" capability=5 >>> scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability >>> permissive=0 >>> 3. avc: denied { kill } for pid=0 comm="swapper/1" capability=5 >>> scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 tclass=capability >>> permissive=0 >>> 4. avc: denied { kill } for pid=4185 comm="kworker/0:4" >>> capability=5 scontext=u:r:kernel:s0 tcontext=u:r:kernel:s0 >>> tclass=capability permissive=0 >>> >>> This is self capability any one in kernel context should be able to >>> do such operations I guess. >> >> The reference policy does contain a rule that allows this kind of >> operations, see: >> https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/kernel/kernel.te#L203 >> >> >> It is also present in the Fedora policy on my system: >> >> $ sesearch -A -s kernel_t -t kernel_t -c capability -p kill >> allow kernel_t kernel_t:capability { audit_control audit_write chown >> dac_override dac_read_search fowner fsetid ipc_lock ipc_owner kill >> lease linux_immutable mknod net_admin net_bind_service net_broadcast >> net_raw setfcap setgid setpcap s >> etuid sys_admin sys_boot sys_chroot sys_nice sys_pacct sys_ptrace >> sys_rawio sys_resource sys_time sys_tty_config }; >> >> Therefore I would say it is perfectly fine to add such rule to your >> policy as well. > > Android uses a completely different policy not based on the reference > policy at all, and tries to limit even the kernel and init domains to > least privilege. There are a few reasons to limit even the kernel domain: > > 1) To protect kernel threads and kernel usermodehelpers from being > tricked into misusing their privileges and ensuring that they always > transition to a non-kernel domain upon executing a usermodehelper. > > 2) To render typical kernel exploits that just switch to the init cred > or otherwise rewrite their cred to use SECINITSID_KERNEL from gaining > full privileges. > > There are no unconfined domains in Android policy. > > I think we would at least want to know why the permission check is > occurring, as it might reflect a kernel bug. If you can get system call > audit info, then you can see additional information that may be helpful. I guess system call audit isn't relevant here since these are kernel-internal callers. This still seems like a kernel bug though, because check_kill_permission() will return 0 without performing any capability or other permission checks if !si_fromuser(info). So kernel callers shouldn't trigger such permission checks unless I missed something. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2018-11-15 15:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CACikiw1uNCYKzo9vjG=AZHpARWv-nzkCX=D-aWBssM7vYZrQdQ@mail.gmail.com> 2018-11-12 10:09 ` Ravi Kumar 2018-11-15 13:11 ` Re: Ondrej Mosnacek 2018-11-15 14:42 ` Android kill capability denials Stephen Smalley 2018-11-15 15:42 ` Stephen Smalley
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.