- Dec 12, 2018
-
-
Nick Kralevich authored
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
-
- Aug 13, 2018
-
-
Nick Kralevich authored
There is a problem with on-disk labeling of files created by secondary dex background compilation which is causing unexpected denials to show up. Drop the auditallow rule to avoid logspam. Steps to reproduce: 1) boot android device. 2) adb root 3) Run cmd package compile -r bg-dexopt --secondary-dex com.google.android.gms 4) Examine the files in /data/user_de/0/com.google.android.gms Expected: All files have the label privapp_data_file Actual: The files in /data/user_de/0/com.google.android.gms/app_chimera/m are labeled "app_data_file", not "privapp_data_file". Addresses the following audit logspam: type=1400 audit(0.0:117): avc: granted { execute } for comm=4173796E635461736B202331 path="/data/user_de/0/com.google.android.gms/app_chimera/m/00000002/oat/arm/DynamiteLoader.odex" dev="dm-0" ino=5775 scontext=u:r:untrusted_app:s0:c111,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.android.chrome Additionally, this removes auditallow statements for older untrusted apps. Lots of big apps are executing files from their home directory. Additional restrictions in this area will need to be tied to API versions. Addresses the following audit logspam: type=1400 audit(0.0:619): avc: granted { execute } for comm="na:notification" path="/data/data/com.facebook.katana/lib-xzs/libbreakpad.so" dev="dm-3" ino=28333 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.facebook.katana type=1400 audit(0.0:129): avc: granted { execute } for comm="ticlock" path="/data/data/is.shortcut/files/ticlock/ticlock" dev="dm-3" ino=58614 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=is.shortcut type=1400 audit(0.0:1239): avc: granted { execute } for comm="Analytics-Norma" path="/data/data/com.facebook.orca/lib-xzs/libchipsetmerged.so" dev="dm-3" ino=50243 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.facebook.orca type=1400 audit(0.0:58): avc: granted { execute_no_trans } for comm="sh" path="/data/data/is.shortcut/files/ticlock/ticlock" dev="dm-3" ino=58614 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=is.shortcut type=1400 audit(0.0:1948): avc: granted { execute_no_trans } for comm="sh" path="/data/data/com.mxdata.tube.Market/files/osmcore" dev="sda13" ino=2752651 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.mxdata.tube.Market type=1400 audit(0.0:2875): avc: granted { execute_no_trans } for comm="ThreadPoolManag" path="/data/data/com.amazon.kindle/files/hardwareTest" dev="sda13" ino=1935346 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.amazon.kindle This reverts commit 4738b93d. Bug: 112357170 Test: policy compiles
-
- Aug 06, 2018
-
-
Nick Kralevich authored
Executing files from an application home directory violates W^X (https://en.wikipedia.org/wiki/W%5EX) constraints (loading executable code from a writable file) and is an unsafe application behavior. Test to see if we can get rid of it and establish some baseline metrics. Test: device boots and no obvious problems. Change-Id: I756c281fcbf750821307327642cc0d06605951b0
-
- Aug 02, 2018
-
-
Nick Kralevich authored
Currently, both untrusted apps and priv-apps use the SELinux file label "app_data_file" for files in their /data/data directory. This is problematic, as we really want different rules for such files. For example, we may want to allow untrusted apps to load executable code from priv-app directories, but disallow untrusted apps from loading executable code from their own home directories. This change adds a new file type "privapp_data_file". For compatibility, we adjust the policy to support access privapp_data_files almost everywhere we were previously granting access to app_data_files (adbd and run-as being exceptions). Additional future tightening is possible here by removing some of these newly added rules. This label will start getting used in a followup change to system/sepolicy/private/seapp_contexts, similar to: -user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user +user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user For now, this newly introduced label has no usage, so this change is essentially a no-op. Test: Factory reset and boot - no problems on fresh install. Test: Upgrade to new version and test. No compatibility problems on filesystem upgrade. Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
-
- Apr 03, 2018
-
-
Nathan Harold authored
Because applications should be able to set the receive timeout on UDP encapsulation sockets, we need to allow setsockopt(). getsockopt() is an obvious allowance as well. Bug: 68689438 Test: compilation Merged-In: I2eaf72bcce5695f1aee7a95ec03111eca577651c Change-Id: I2eaf72bcce5695f1aee7a95ec03111eca577651c
-
Nathan Harold authored
Because applications should be able to set the receive timeout on UDP encapsulation sockets, we need to allow setsockopt(). getsockopt() is an obvious allowance as well. Bug: 68689438 Test: compilation Change-Id: I2eaf72bcce5695f1aee7a95ec03111eca577651c
-
- Jan 15, 2018
-
-
Nathan Harold authored
This gives the privilege to system apps, platform apps, ephemeral apps, and privileged apps to receive a UDP socket from the system server. This is being added for supporting UDP Encapsulation sockets for IPsec, which must be provided by the system. This is an analogous change to a previous change that permitted these sockets for untrusted_apps: 0f75a62e Bug: 70389346 Test: IpSecManagerTest, System app verified with SL4A Change-Id: Iec07e97012e0eab92a95fae9818f80f183325c31
-
- Jan 10, 2018
-
-
Primiano Tucci authored
Perfetto is a performance instrumentation and logging framework, living in AOSP's /external/pefetto. Perfetto introduces in the system one binary and two daemons (the binary can specialize in either depending on the cmdline). 1) traced: unprivileged daemon. This is architecturally similar to logd. It exposes two UNIX sockets: - /dev/socket/traced_producer : world-accessible, allows to stream tracing data. A tmpfs file descriptor is sent via SCM_RIGHTS from traced to each client process, which needs to be able to mmap it R/W (but not X) - /dev/socket/traced_consumer : privilege-accessible (only from: shell, statsd). It allows to configure tracing and read the trace buffer. 2) traced_probes: privileged daemon. This needs to: - access tracingfs (/d/tracing) to turn tracing on and off. - exec atrace - connect to traced_producer to stream data to traced. init.rc file: https://android-review.googlesource.com/c/platform/external/perfetto/+/575382/14/perfetto.rc Bug: 70942310 Change-Id: Ia3b5fdacbd5a8e6e23b82f1d6fabfa07e4abc405
-
- Nov 13, 2017
-
-
Chad Brubaker authored
This restriction causes issues with dynamite. Since untrusted_v2_app was about enforcing this constraint put installed v2 applications back into the normal untrusted_app domain. Bug: 64806320 Test: Manual test with app using dynamite module (cherrypicked from commit fe836817) Change-Id: I3abf3ade64aaf689039a515de642759dd39ae6f7
-
- Nov 09, 2017
-
-
Jeff Vander Stoep authored
Vendor apps may only use servicemanager provided services marked as app_api_service. surfaceflinger_service should be available to vendor apps, so add this attribute and clean up duplicate grants. Addresses: avc: denied { find } scontext=u:r:qtelephony:s0 tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager avc: denied { find } scontext=u:r:ssr_detector:s0 tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager avc: denied { find } scontext=u:r:qcneservice:s0 tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager Bug: 69064190 Test: build Change-Id: I00fcf43b0a8bde232709aac1040a5d7f4792fa0f
-
- Oct 25, 2017
-
-
Chad Brubaker authored
This restriction causes issues with dynamite. Since untrusted_v2_app was about enforcing this constraint put installed v2 applications back into the normal untrusted_app domain. Bug: 64806320 Test: Manual test with app using dynamite module Change-Id: I3abf3ade64aaf689039a515de642759dd39ae6f7
-
- Oct 04, 2017
-
-
Marco Nelissen authored
so they can use MediaExtractor too. Bug: 67406992 Test: yes Change-Id: Iaacadc13b1fc032fe31eea1f3ecbbbabb741470a
-
- Sep 26, 2017
-
-
Dan Cashman authored
Bug: 37916906 Test: Builds 'n' boots. Change-Id: Ia1d86264446ebecc1ca79f32f11354921bc77668 Merged-In: I208ec6a864127a059fb389417a9c6b259d7474cb
-
- Jun 16, 2017
-
-
Chong Zhang authored
bug: 22804304 Change-Id: I7162905d698943d127aa52804396e4765498d028
-
- May 30, 2017
-
-
Chad Brubaker authored
Bug: 62102558 Test: see b/62102558 Change-Id: If80d1270bcf6835e6d1a78e2176c3e139cebd174
-
- Mar 29, 2017
-
-
Chad Brubaker authored
Test: denials go away Change-Id: I103cf3ad8d86b461bcba8edce02f6202fd2bcbe8
-
- Mar 24, 2017
-
-
Alex Klyubin authored
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor apps) are not permitted to use Binder. This commit thus: * groups non-vendor domains using the new "coredomain" attribute, * adds neverallow rules restricting Binder use to coredomain and appdomain only, and * temporarily exempts the domains which are currently violating this rule from this restriction. These domains are grouped using the new "binder_in_vendor_violators" attribute. The attribute is needed because the types corresponding to violators are not exposed to the public policy where the neverallow rules are. Test: mmm system/sepolicy Test: Device boots, no new denials Test: In Chrome, navigate to ip6.me, play a YouTube video Test: YouTube: play a video Test: Netflix: play a movie Test: Google Camera: take a photo, take an HDR+ photo, record video with sound, record slow motion video with sound. Confirm videos play back fine and with sound. Bug: 35870313 Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
-
- Mar 21, 2017
-
-
Chad Brubaker authored
Test: Boots, runs Bug: 32713782 Change-Id: Ia58db3c4c0159482f08e72ef638f3e1736095918
-
- Mar 02, 2017
-
-
Alex Klyubin authored
This starts with the reduction in the number of services that ephemeral apps can access. Prior to this commit, ephemeral apps were permitted to access most of the service_manager services accessible by conventional apps. This commit reduces this set by removing access from ephemeral apps to: * gatekeeper_service, * sec_key_att_app_id_provider_service, * wallpaper_service, * wifiaware_service, * wifip2p_service, * wifi_service. Test: Device boots up fine, Chrome, Play Movies, YouTube, Netflix, work fine. Bug: 33349998 Change-Id: Ie4ff0a77eaca8c8c91efda198686c93c3a2bc4b3
-
- Feb 06, 2017
-
-
Chad Brubaker authored
The rules for the two types were the same and /data/app-ephemeral is being removed. Remove these types. Test: Builds Change-Id: I520c026395551ad1362dd2ced53c601d9e6f9b28
-
- Jan 19, 2017
-
-
Chad Brubaker authored
Ephemeral apps cannot open files from external storage, but can be given access to files via the file picker. Test: ACTION_OPEN_DOCUMENTS from an ephemeral app returns a readable fd. Change-Id: Ie21b64a9633eff258be254b9cd86f282db1509e8
-
Chad Brubaker authored
Ephemeral apps are still apps with very similar capabilities, it makes more sense to have them under appdomain and benefit from the shared state (and all the neverallow rules) than to try and dupplicate them and keep them in sync. This is an initial move, there are parts of ephemeral_app that still need to be locked down further and some parts of appdomain that should be pushed down into the various app domains. Test: Builds, ephemeral apps work without denials. Change-Id: I1526b2c2aa783a91fbf6543ac7f6d0d9906d70af
-
- Jan 09, 2017
-
-
Alex Klyubin authored
This leaves only the existence of ephemeral_app domain as public API. All other rules are implementation details of this domain's policy and are thus now private. There are a few rules, defined by other domains' files remaining in the public policy until the rules from these domains also move to the private policy: allow ephemeral_app_current appdomain:binder transfer; allow ephemeral_app_current audioserver_current:binder transfer; allow ephemeral_app_current drmserver_current:binder transfer; allow ephemeral_app_current dumpstate_current:binder transfer; allow ephemeral_app_current mediaserver_current:binder transfer; allow ephemeral_app_current surfaceflinger_current:binder transfer; allow ephemeral_app_current system_server_current:binder transfer; Test: No change to policy according to sesearch, except for disappearance of all allow rules from platform_app_current attribute (as expected). Bug: 31364497 Change-Id: I98687181434a98a141469ef676c461fcd1db2d4e
-
- Dec 06, 2016
-
-
dcashman authored
In order to support platform changes without simultaneous updates from non-platform components, the platform and non-platform policies must be split. In order to provide a guarantee that policy written for non-platform objects continues to provide the same access, all types exposed to non-platform policy are versioned by converting them and the policy using them into attributes. This change performs that split, the subsequent versioning and also generates a mapping file to glue the different policy components together. Test: Device boots and runs. Bug: 31369363 Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317
-
- Oct 07, 2016
-
-
Chad Brubaker authored
Test: Builds and boots Change-Id: I3db64e12f0390c6940f5745eae83ce7efa7d65a9
-
- Oct 06, 2016
-
-
dcashman authored
Divide policy into public and private components. This is the first step in splitting the policy creation for platform and non-platform policies. The policy in the public directory will be exported for use in non-platform policy creation. Backwards compatibility with it will be achieved by converting the exported policy into attribute-based policy when included as part of the non-platform policy and a mapping file will be maintained to be included with the platform policy that maps exported attributes of previous versions to the current platform version. Eventually we would like to create a clear interface between the platform and non-platform device components so that the exported policy, and the need for attributes is minimal. For now, almost all types and avrules are left in public. Test: Tested by building policy and running on device. Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
-