Thank you both. From reading Williams answer I made a quick local test.te: # Allow reaping by init_shell. allow domain init_shell:process sigchld;
This "fixed" the denial, but I understand this is not an optimal solution. Answering Stephens question, only zygote right now: teemodk endeavoru # adb shell ps -Z | grep zygote u:r:zygote:s0 root 153 1 zygote Regarding gdbserver - not that I know of, but I am really new to Android/Linux building. Just want to understand the SEPolicy :) Thanks On Fri, Feb 14, 2014 at 8:31 PM, Stephen Smalley <[email protected]>wrote: > Are you running a gdbserver --attach from the init_shell? > > On Fri, Feb 14, 2014 at 1:49 PM, Stephen Smalley > <[email protected]> wrote: > > So you are running the su daemon in the init domain (started via > > install-recovery.sh) and when it executes a shell, the default > > transition is to init_shell. Which isn't really the way things are > > intended to work; this is a misuse of the pre-existing > > install-recovery.sh service to launch su and the fact that we happen > > to have a transition for shell commands launched by init*.rc files in > > our policy. Given that we now explicitly label the console service > > via a seclabel entry and most of the init*.rc file shell command > > instances now also use seclabel, I wonder if we shouldn't get rid of > > init_shell altogether. > > Is anything running in zygote domain other than the zygote process > > itself? ps -Z | grep zygote > > The sigchld denial means that either a process in the zygote domain is > > trying to send SIGCHLD to a process in the init_shell domain or a > > process in the init_shell domain is calling wait() on a process in the > > zygote domain. Wouldn't normally expect zygote to be spawned from > > init_shell, so that seems wrong. > > > > On Fri, Feb 14, 2014 at 8:56 AM, Tomas <[email protected]> wrote: > >> Hi, I am getting sigchild denials below, that I cannot figure out. > >> They only appear when using su access. Eg. when root-explorer or other > >> utility list files or processes. > >> Not sure if I understand the message correct; who is actually sending > the > >> sigchld and why is it denied? > >> > >> I am unable to find logs from other devices showing samme denial. Using > same > >> BusyBox as many other. > >> > >> Thanks > >> Tomas > >> > >> { sigchld } for > >> pid=5594 comm="sh" > >> scontext=u:r:zygote:s0 > >> tcontext=u:r:init_shell:s0 > >> tclass=process > >> > >> # adb shell su 0 ps -Z | grep sh > >> u:r:adbd:s0 shell 177 1 /sbin/adbd > >> u:r:shell:s0 shell 5064 177 /system/bin/sh > >> u:r:init_shell:s0 root 5262 5260 sh > >> u:r:init_shell:s0 root 5496 5262 sh > >> u:r:init_shell:s0 root 5594 5593 sh > >> > >> -rwxr-xr-x root shell u:object_r:shell_exec:s0 mksh > >> lrwxrwxrwx root root u:object_r:shell_exec:s0 sh -> > mksh > >> > >> ------ BusyBox: ------ > >> root@android:/ # ps -Z | grep su > >> u:r:init:s0 root 176 1 /system/xbin/su > >> u:r:su:s0 root 5254 5064 su > >> u:r:su:s0 root 5255 5254 su > >> u:r:init:s0 root 5258 1 /system/xbin/su > >> u:r:init:s0 root 5260 5258 /system/xbin/su > >> u:r:untrusted_app:s0 u0_a61 5589 1950 /system/bin/su > >> u:r:untrusted_app:s0 u0_a61 5590 5589 /system/bin/su > >> u:r:init:s0 root 5592 1 /system/xbin/su > >> u:r:init:s0 root 5593 5592 /system/xbin/su > >> u:r:su:s0 root 6598 6297 su > >> u:r:su:s0 root 6599 6598 su > >> u:r:init:s0 root 6601 1 /system/xbin/su > >> u:r:init:s0 root 6603 6601 /system/xbin/su > >> > >> # adb shell su 0 ls -Z /system/bin/ | grep su > >> lrwxrwxrwx root root u:object_r:system_file:s0 su -> > >> ../xbin/su > >> # adb shell su 0 ls -Z /system/xbin/| grep su > >> -rwsr-sr-x root root u:object_r:su_exec:s0 su > >> > >> > >> _______________________________________________ > >> 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].
