Thank you very much Tai
On 2/14/14, 1:37 PM, "Stephen Smalley" <[email protected]> wrote: >This is allowed in our current policy (and AOSP master), although we >would prefer to put all such libraries into their own type managed by >the OS (this is what in fact happens if you package the shared library >in the officially supported manner rather than manually extracting or >downloading the shared libraries). >See https://android-review.googlesource.com/#/c/72060/2 > >On Thu, Feb 13, 2014 at 9:25 PM, Tai Nguyen (tainguye) ><[email protected]> wrote: >> I got this audit message when running the Xray app >> >> audit(1390917101.250:6): avc: denied { execute } for pid=5371 >> comm=4173796E635461736B202331 >> path="/data/data/com.duosecurity.xray/files/libashmem_v1.so" dev=dm-0 >> ino=155658 scontext=u:r:untrusted_app:s0 >> tcontext=u:object_r:app_data_file:s0 tclass=file >> >> It seems like it just uses its code, so it should be allowed to do that. >> However, I look at the app.te and we only give app_domain >>create_file_perms >> which doesn't include executable permission. >> >> # App sandbox file accesses. >> >> allow appdomain app_data_file:dir create_dir_perms; >> >> allow appdomain app_data_file:notdevfile_class_set create_file_perms; >> >> >> So, why don't we give app domain executable permission for its data >>file? >> >> Thanks, >> Tai >> >> >> >> _______________________________________________ >> 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].
