I want to re-emphasize what Stephen said about packaging the .so with the APK. This is the only correct solution. As a platform keys signed application, you have a lot of power and responsibility. We want to ensure that applications signed with this key are only running known good trusted code from a trustworthy, unwritable directory. Loading a .so file out of the app's home directory is just asking for problems.
Any other solutions are just hacks, and they won't be supported. -- Nick On Wed, Feb 4, 2015 at 6:11 AM, Stephen Smalley <[email protected]> wrote: > On 02/04/2015 08:48 AM, Stephen Smalley wrote: > > On 02/04/2015 04:58 AM, kore saravappa wrote: > >> Hi, > >> > >> I am checking on permissive and Enforcing mechanism of selinux(SE Linux) > >> in Android 5.0. I have placed .so file in > >> /data/data/packageName/files/libtestcalc.so. > >> > >> when the device is in permissive mode, > >> System.load("/data/data/packageName/files/libtestcalc.so"); - works fine > >> and I am able to access the methods of .so file with out any exceptions. > >> > >> The same, System.load("/data/data/packageName/files/libtestcalc.so"); is > >> not working when the device is in Enforcing mode and I am getting > >> exception as follows. > >> > >> java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map > >> "/data/data/packageName/files/libtestcalc.so" segment 1: Permission > denied > >> > >> I guess in both the modes, same call flow will occur. I mean > >> > System.load(..)->Runtime.getRuntime().load(..)->Runtime.getRuntime(..).doload(..)->Runtime.getRuntime().nativeLoad(..) > >> > >> @Runtime.java->doLoad(..) documentation mentioned as "nativeLoad should > >> be synchronized so there's only one LD_LIBRARY_PATH in use > regardless..." > >> > >> How android is differentiating the load files by modes? Want to know > >> other ways to load .so file from "/data/data/packageName/files/". > >> > >> At following syntax, > >> System.load("/data/data/packageName/files/libtestcalc.so"); > >> I will following Warning: > >> > >> type=1400 audit(0.0:41): avc: denied { execute } for > >> path="/data/data/packageName/files/libapscreen.so" dev=mmcblk0p12 > >> ino=586898 scontext=u:r:platform_app:s0 > >> tcontext=u:object_r:app_data_file:s0 tclass=file > >> > >> Error as: > >> E/art : dlopen("/data/data/packageName/files/libapscreen.so", RTLD_LAZY) > >> failed: dlopen failed: couldn't map > >> "/data/data/packageName/files/libapscreen.so" segment 1: Permission > denied > >> java.lang.UnsatisfiedLinkError: dlopen failed: couldn't map > >> "/data/data/packageName/files/libtestcalc.so" segment 1: Permission > denied > >> > >> How SELinux will differentiating these loading files? > > > > The preferred approach is to package the .so file using the Android NDK > > such that Android will extract it to the lib directory, not as an asset > > of the package that is unpacked by the app into its files directory on > > first execution. Then, the file will be labeled with a system_data_file > > type that is executable but not writable by apps. > > > > The other approach would be to introduce a separate type for > > platform_app /data/data directories and only allow execute to that type. > > We used to have such a type (platform_app_data_file) but it wasn't a > > useful distinction in the AOSP policy because even untrusted_app > > sometimes needs read/write to it. And the AOSP apps do not package .so > > files as assets and therefore do not trigger the execute denial you are > > encountering, so we would not have seen this issue in AOSP. If you want > > to try resurrecting that type, you could revert commit > > dc88dca115791053d00354785be37a38259b3781 aka Change-Id > > Ic15066f48765322ad40500b2ba2801bb3ced5489 . > > On second thought, I wouldn't really recommend the latter as that will > cause a divergence with AOSP that could have rippling effects. It might > be something we should do in AOSP master for future releases. > > It would be better if you could instead just fix the app to package the > .so file via the Android NDK. Failing that, you could allow this > permission in your device-specific policy but that will expose your > platform apps to possible code injection from untrusted apps. > > > _______________________________________________ > Seandroid-list mailing list > [email protected] > To unsubscribe, send email to [email protected]. > To get help, send an email containing "help" to > [email protected]. > -- Nick Kralevich | Android Security | [email protected] | 650.214.4037
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
