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 .
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
