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].
