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