On 11/27/2013 07:37 AM, Severin Friede wrote:
> Dear Mr. Smalley
>
> thank you for your answer, I really appreciate that!
>
> as I mentioned, I wrote 2 test apps (s1 & s2). both are able to read and
> write a file to their own internal storage folder and to a common folder on
> the external storage (sdcard). So far it works as expected.
>
> 1) I create the external sdcard for an emulator with mksdcard, the
> filesystem is fat32, so unfortunatly this won't work like you've explained.
>
> 2.) I tried to deny write permissions to internal and external storage for
> 3rd party apps (untrusted apps). I modified the "untrusted_app.te" file and
> uncomment the following lines:
>
> # Internal SDCard rw access.
> #allow untrustedappdomain sdcard_internal:dir create_dir_perms;
> #allow untrustedappdomain sdcard_internal:file create_file_perms;
>
> # External SDCard rw access.
> #allow untrustedappdomain sdcard_external:dir create_dir_perms;
> #allow untrustedappdomain sdcard_external:file create_file_perms;
>
> Then I rebuild the policy and loaded it through the SEAdmin App:
>
> buildsebundle -k build/target/product/security/testkey.pk8
> out/target/product/manta/root/*
>
> adb push selinux_bundle.zip /sdcard/
>
> this stayed without success so I tried a different method
Sorry, did you trigger the reload via SEAdmin after pushing the bundle?
What error did you get? Did it unpack the files under /data/security?
What version of Android are you using - master, 4.4, 4.3?
> make sepolicy
> adb push out/target/product/<device>/root/sepolicy /data/security/current
>
> adb shell su 0 setprop selinux.reload_policy 1
>
> this won't worked either. Then I recognized that it is possible to turn
> off/on the read/write permissions for apps through adb shell, so i tried
>
> app_internal_sdcard_rw false
> app_external_sdcard_rw false
>
> without any success. When running getsebool I don't get the above described
> variables listed in the output:
>
> android_cts --> off
> disableAudio --> off
> disableAudioCapture --> off
> disableBluetooth --> off
> disableCamera --> off
> manage_mac --> on
> manage_selinux --> on
> support_runas --> on
Yes, the booleans were removed because AOSP made the rules unconditional
and we followed suit when we merged. AOSP doesn't really like policy
booleans / conditional policy; they want a single policy that just works.
> Do you have any idea why I can't disable the write functions for untrusted
> apps? what am I doing wrong?
>
> 3.) Quote: "Our default policy specifies levelFrom=app
> in external/sepolicy/seapp_contexts for untrusted apps (third party
> apps)...."
>
> I tried to verify this. When I tried to read the internal storage from app
> s2 through app s1 I get an "EACCESS Permission Denied" error.
>
> the output ps -Z, ls -Z and of audit.log seems to be as you've described it.
>
> audit.log:
>
> type=1400 msg=audit(1385553008.449:243): avc: denied { getattr } for
> pid=1156 comm="ps" scontext=u:r:shell:s0
> tcontext=u:r:untrusted_app:s0:c47,c256 tclass=process
> type=1400 msg=audit(1385553008.449:244): avc: denied { getattr } for
> pid=1156 comm="ps" scontext=u:r:shell:s0
> tcontext=u:r:untrusted_app:s0:c48,c256 tclass=process
>
> ps -Z:
>
> u:r:untrusted_app:s0:c47,c256 u0_a47 1065 58
> com.example.seandroid_readfiles
> u:r:untrusted_app:s0:c48,c256 u0_a48 1117 58
> com.example.seandroid_storefiles
>
> ls -Z:
>
> drwxr-x--x u0_a47 u0_a47 u:object_r:app_data_file:s0:c47,c256
> com.example.seandroid_readfiles
>
> drwxr-x--x u0_a48 u0_a48 u:object_r:app_data_file:s0:c48,c256
> com.example.seandroid_storefiles
>
>
>
> But the "EACCESS Permission Denied" error even exists with an Android 4.0
> Image without the SEAndroid Extension. The File was stored with
> "Context.MODE_WORLD_WRITEABLE". Just to satisfy my curiosity, I always
> thought that android does this seperation by default through the kernel's
> UID's and GID's?
Um, what about MODE_WORLD_READABLE? Didn't you say you were trying to
read the file? Do an ls -Z of the actual file.
Android does provide UID-based separation of apps, but a) that still
allows a flawed or malicious app to leave its files world-readable or
-writable, thereby exposing them to other apps, and b) DAC is rather
lacking in its completeness and privilege model. That's all discussed
in our NDSS paper,
http://www.internetsociety.org/sites/default/files/02_4.pdf
--
This message was distributed to subscribers of the seandroid-list mailing list.
If you no longer wish to subscribe, send mail to [email protected] with
the words "unsubscribe seandroid-list" without quotes as the message.
