I don't know if that simplifies the upgrade process. You have to create a system for it rather then use what Google already made.
Suppose the case I'm attacking your app and can get your app to write arbitrary output to that lib. Bingo...that apps not malicious but another one was. Also consider the case that app accidentally made it world writable(dumb but I've seen many chmod 777s just to get it to work)...again just inject your code. I'm not advocating against it. For comparability it may need to be allowed. Are you on master or up to date? On Feb 13, 2014 8:34 PM, "Tai Nguyen (tainguye)" <[email protected]> wrote: > Hi Bill, > > Agreed with you about the combination of write and executable is bad. > However, given that the app is already installed on the device, if it is > malicious, the damage is already done. So I'm not sure preventing that > malicious app to inject more code has great value. > > Also, I noticed that when I started some app initially it starts > downloading more code before fully functioning. I wonder if the developers > do it to minimize the size of the app in play store as well as to > simplifying the upgrade process (i.e., doesn't need to upgrade the version > in play store). > > > From: William Roberts <[email protected]> > Date: Thursday, February 13, 2014 at 10:42 PM > To: Tai Nguyen <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: Missing executable permission for app domain to use its > shared library? > > In general you should avoid write and execute together. Its an entry > point for code injection. However, apps that DL their own so files for > dynamic loading will trigger this. > > The proper way of app updating is Google play. The proper way of running > libraries is to pkg them with the apk. Apps however don't do this. I'm > curious if this rule is on aosp master..and if not is this bad practice > going to be stopped. > On Feb 13, 2014 6:27 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].
