PWN-Hunter/android_system_sepolicy
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
8c0a066211
android_system_sepolicy/private/rs.te

40 lines
1.4 KiB
Plaintext
Raw Normal View History

bless app created renderscript files 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
2018-12-12 09:06:05 -08:00
# Any files which would have been created as app_data_file
rename rs_data_file to app_exec_data_file 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
2019-01-11 09:37:46 -08:00
# will be created as app_exec_data_file instead.
bless app created renderscript files 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
2018-12-12 09:06:05 -08:00
allow rs app_data_file:dir ra_dir_perms;
rename rs_data_file to app_exec_data_file 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
2019-01-11 09:37:46 -08:00
allow rs app_exec_data_file:file create_file_perms;
type_transition rs app_data_file:file app_exec_data_file;
bless app created renderscript files 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
2018-12-12 09:06:05 -08:00
rs.te: Allow following /data/user/0 symlink 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
2018-12-19 12:09:42 -08:00
# Follow /data/user/0 symlink
allow rs system_data_file:lnk_file read;
bless app created renderscript files 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
2018-12-12 09:06:05 -08:00
# Read files from the app home directory.
allow rs app_data_file:file r_file_perms;
allow rs app_data_file:dir r_dir_perms;
rename rs_data_file to app_exec_data_file 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
2019-01-11 09:37:46 -08:00
# Cleanup app_exec_data_file files in the app home directory.
bless app created renderscript files 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
2018-12-12 09:06:05 -08:00
allow rs app_data_file:dir remove_name;
# Use vendor resources
allow rs vendor_file:dir r_dir_perms;
r_dir_file(rs, vendor_overlay_file)
r_dir_file(rs, vendor_app_file)
# Read contents of app apks
r_dir_file(rs, apk_data_file)
allow rs gpu_device:chr_file rw_file_perms;
allow rs ion_device:chr_file r_file_perms;
allow rs same_process_hal_file:file { r_file_perms execute };
# File descriptors passed from app to renderscript
rs.te: Allow ephemeral_app FD use 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
2019-04-02 13:48:39 -07:00
allow rs { untrusted_app_all ephemeral_app }:fd use;
rs: add tests to ensure rs cannot abuse app data Test: build Change-Id: I2ea39c767264339e300fceeb23c506883d23a14c
2019-01-17 14:44:29 -08:00
# rs can access app data, so ensure it can only be entered via an app domain and cannot have
# CAP_DAC_OVERRIDE.
neverallow rs rs:capability_class_set *;
neverallow { domain -appdomain } rs:process { dyntransition transition };
neverallow rs { domain -crash_dump }:process { dyntransition transition };
neverallow rs app_data_file:file_class_set ~r_file_perms;
# rs should never use network sockets
neverallow rs *:network_socket_class_set *;
Reference in New Issue Copy Permalink