Allow renderscript to use file descriptors created by ephemeral apps.
This is needed to support renderscript execution by ephemeral apps.
Steps to reproduce:
atest com.google.android.pm.gts.PackageManagerHostTest#testRenderScriptLoading
Expected:
Test passes
Actual:
03-26 03:33:45.373 4607 4607 F linker : CANNOT LINK EXECUTABLE "/system/bin/bcc": can't enable GNU RELRO protection for "": Permission denied
03-26 03:33:45.373 4566 4600 E RenderScript: Child process "/system/bin/bcc" terminated with status 256
03-26 03:33:45.373 4566 4600 E RenderScript: bcc: FAILS to compile 'init_test'
03-26 03:33:45.374 4566 4596 E TestRunner: failed: testRenderScriptLoading(com.google.android.gts.packagemanager.InstantAppTestCases)
03-26 03:33:45.375 4566 4596 E TestRunner: ----- begin exception -----
03-26 03:33:45.375 4566 4596 E TestRunner: java.lang.AssertionError: Instant App should be able to access RenderScript APIs.
03-26 03:33:45.375 4566 4596 E TestRunner: at org.junit.Assert.fail(Assert.java:88)
03-26 03:33:45.375 4566 4596 E TestRunner: at com.google.android.gts.packagemanager.InstantAppTestCases.testRenderScriptLoading(InstantAppTestCases.java:338)
03-26 03:33:45.375 4566 4596 E TestRunner: at java.lang.reflect.Method.invoke(Native Method)
03-26 03:33:45.375 4566 4596 E TestRunner: at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
Additional notes: Confusingly ephemeral_app is not part of untrusted_app_all,
but it is part of all_untrusted_apps, which is used for neverallow
assertions.
Bug: 129356700
Test: atest com.google.android.pm.gts.PackageManagerHostTest#testRenderScriptLoading
Change-Id: I47781012b9fd2cd1d03a3d50bed0c693bcf9ec7b
These dontaudit rules were in place to suppress SELinux denials due to
file descriptor leakage. The file descriptor leakage has been fixed, so
these rules are no longer necessary. Delete.
Fixes: 120983106
Test: cts-tradefed run cts-dev -m CtsRenderscriptTestCases
Change-Id: I5cad79c3526583bd2b65bd089fee9c490f6beb5e
There are multiple trusted system components which may be responsible
for creating executable code within an application's home directory.
Renderscript is just one of those trusted components.
Generalize rs_data_file to app_exec_data_file. This label is intended to
be used for any executable code created by trusted components placed
into an application's home directory.
Introduce a typealias statement to ensure files with the previous label
continue to be understood by policy.
This change is effectively a no-op, as it just renames a type, but
neither adds or removes any rules.
Bug: 121375718
Bug: 112357170
Test: cts-tradefed run cts-dev -m CtsRenderscriptTestCases
Change-Id: I17dca5e3e8a1237eb236761862174744fb2196c0
Add "rs" and "rs_exec" types to public policy. Access
to these types might be needed for device specific
customization.
Bug: 121306110
Test: Manual using application
Change-Id: Ief35d3353625adfbf468447de74aa80651dd9451
The bcc command line uses /data/user/0 paths, so renderscript needs to
be able to follow those symlinks.
Addresses the following denial:
audit(1545249938.830:2274): avc: denied { read } for comm="bcc" name="0" dev="dm-6" ino=101 scontext=u:r:rs:s0:c184,c256,c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=lnk_file permissive=1 app=android.rscpp.cts
Test: cts-tradefed run cts -m CtsRsCppTestCases
Bug: 121266184
Bug: 112357170
Change-Id: I16210f9b95f386bdee0863cf0044c956af99586d
When an app uses renderscript to compile a Script instance,
renderscript compiles and links the script using /system/bin/bcc and
/system/bin/ld.mc, then places the resulting shared library into the
application's code_cache directory. The application then dlopen()s the
resulting shared library.
Currently, this executable code is writable to the application. This
violates the W^X property (https://en.wikipedia.org/wiki/W%5EX), which
requires any executable code be immutable.
This change introduces a new label "rs_data_file". Files created by
/system/bin/bcc and /system/bin/ld.mc in the application's home
directory assume this label. This allows us to differentiate in
security policy between app created files, and files created by
renderscript on behalf of the application.
Apps are allowed to delete these files, but cannot create or write these
files. This is enforced through a neverallow compile time assertion.
Several exceptions are added to Treble neverallow assertions to support
this functionality. However, because renderscript was previously invoked
from an application context, this is not a Treble separation regression.
This change is needed to support blocking dlopen() for non-renderscript
/data/data files, which will be submitted in a followup change.
Bug: 112357170
Test: cts-tradefed run cts -m CtsRenderscriptTestCases
Change-Id: Ie38bbd94d26db8a418c2a049c24500a5463698a3
