Okey. Thank you for your help!
2015-06-16 0:26 GMT+09:00 Stephen Smalley <[email protected]>:
> frameworks/base/cmds/app_process/app_main.cpp calls
> prctl(PR_SET_NO_NEW_PRIVS...). So nothing launched via it is allowed to
> change credentials via execve, whether via setuid, setgid,
> file-capabilities or SELinux.
>
> On 06/12/2015 10:23 PM, Jaejyn Shin wrote:
> > Thank you for your explanation
> >
> >> Second, execute_no_trans is a permission check that occurs when you are
> >> not transitioning domains; it is used to prevent a process from
> >> unwittingly running a program without changing to a different domain,
> >> e.g. to shed privileges. The fact that you are still falling back to an
> >> execute_no_trans check even when you have defined an automatic
> >> transition is surprising; it suggests that either you didn't build,
> >> flash, and reboot with that policy or that something else is suppressing
> >> the domain transition (nosuid mount or prctl PR_SET_NO_NEW_PRIVS).
> >
> > I checked my device have the domain transition permission
> > (domain_auto_trans(shell, toolbox_exec, toolbox))
> >
> > Then, I have to check the "nosuid mount or prctl PR_SET_NO_NEW_PRIVS".
> >
> > And also.. In the hooks.c
> > ===========================================================
> > if (new_tsec->sid == old_tsec->sid) {
> > rc = avc_has_perm(old_tsec->sid, isec->sid,
> > SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, &ad);
> > if (rc)
> > return rc;
> > } else {
> > /* Check permissions for the transition. */
> > rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> > SECCLASS_PROCESS, PROCESS__TRANSITION, &ad);
> > ===========================================================
> >
> > If the two sid was different, the sequence had to flew to the next
> > following else statement (/* Check permissions for the transition.
> > */) statement and checked the domain transition permission.
> >
> > I checked the code flow to see the possibility if the new_tsec->sid ==
> > old_tsec->sid.
> >
> > At first shell executed process_a and then process_a executed
> toolbox_exec.
> >
> > 1. adb shell process_a
> > 2. In the process_a.java
> > Runtime.getRuntime().exec(LOGCAT_CMD);
> >
> > If the domain of process_a is shell domain and the
> > "Runtime.getRuntime().exec()" function invoke shell domain,
> > then the new_tsec->sid and the old_tsec->sid can get a same shell domain.
> >
> > This is only my assumption.
> >
> > In this case, we can get the execute_no_trans violation although we
> > already have domain transition permission (domain_auto_trans)
> >
> > I wonder if my this assumption is correct or not.
> >
> > And how can I check "something else is suppressing the domain transition
> > (nosuid mount or prctl PR_SET_NO_NEW_PRIVS)." ?
> >
> > Thank you
> > Best regards
> >
> >
> >
> > 2015-06-12 21:53 GMT+09:00 Stephen Smalley <[email protected]
> > <mailto:[email protected]>>:
> >
> > On 06/11/2015 09:04 PM, Jaejyn Shin wrote:
> > > Dear SEAndroid developers
> > > Always thank your for your help.
> > >
> > > I saw the bellow denial log
> > >
> > > *avc: denied { execute_no_trans } for pid=18451 comm="process_a"
> > > path="/system/bin/toolbox" dev="mmcblk0p53" ino=916
> > > scontext=u:r:shell:s0 tcontext=u:object_r:toolbox_exec:s0
> tclass=file
> > > permissive=1*
> > >
> > > But my device already have the following policy
> > >
> > > *domain_auto_trans(shell, toolbox_exec, toolbox)*
> > >
> > > Certainly I allowed the domain transition but I wonder why
> > > execute_no_trans violation arose.
> > >
> > > After looking into the kernel source, I found some hints in the
> hooks.c
> > >
> > > *if (new_tsec->sid == old_tsec->sid) {*
> > > *rc = avc_has_perm(old_tsec->sid, isec->sid,*
> > > * SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, &ad);*
> > > *if (rc)*
> > > *return rc;*
> > > *} else {*
> > >
> > > Then... my question is...
> > > Was the denials log arisen because both of scontext=u:r:shell:s0
> and
> > > tcontext=u:object_r:toolbox_exec:s0 have same sid ?
> > >
> > > Thank you
> > > Best regards
> >
> > First, you do not want to add domain_auto_trans(shell, toolbox_exec,
> > toolbox) to your policy. The toolbox domain is only for running
> mkswap
> > via libfsmgr from init, and runs with significant privileges in
> order to
> > access raw swap partitions. It is only supposed to be used for init.
> > Most programs that execute toolbox should just stay in their own
> domain
> > and run with the same permissions.
> >
> > Second, execute_no_trans is a permission check that occurs when you
> are
> > not transitioning domains; it is used to prevent a process from
> > unwittingly running a program without changing to a different domain,
> > e.g. to shed privileges. The fact that you are still falling back
> to an
> > execute_no_trans check even when you have defined an automatic
> > transition is surprising; it suggests that either you didn't build,
> > flash, and reboot with that policy or that something else is
> suppressing
> > the domain transition (nosuid mount or prctl PR_SET_NO_NEW_PRIVS).
> >
> > Third, you only get the same SID for the same context.
> >
> > Fourth, AOSP policy allows all domains except kernel and init to
> > execute_no_trans toolbox_exec, from domain.te:
> > # Run toolbox.
> > # Kernel and init never run anything without changing domains.
> > allow { domain -kernel -init } toolbox_exec:file rx_file_perms;
> >
> > This was to prevent breakage for many domains when we introduced the
> > separate toolbox domain, as many domains previously were able to
> > execute_no_trans it as system_file. At some point I'd like to see
> that
> > reduced to only those domains that truly need it.
> >
> >
> >
> >
> > _______________________________________________
> > 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].
>
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
