am: 3259f98c

Change-Id: I9c4cea46a1b5272974b484eeaa01a87ac41a8bdf

am: 8ad09d93

Change-Id: I745c85dd761cc68e0301a7a3fa32b29269c624d2

am: 608969b3

Change-Id: I99225c48524600248d3d76a56368dc96da67caa0

am: 16eb632a

Change-Id: Ifb5f7fd54973cf1de256404344bd8690a4f13c02

am: eb710332

Change-Id: I15f27cd755e5a8556e189af50b8bca52f050ad8f

am: db5962ce

Change-Id: I4ce4248dd0f780c1d466a7798a159d854d30a09a

This was accidentally omitted from all_untrusted_app

While I'm here, split across mutiple lines and alphabetize.

Test: policy compiles.
Change-Id: I7fe1d1d0a4ef2ed3ab010931ee2ba15637c2be51

am: 9829506c

Change-Id: I7a05cbb58ebbe4d23c9fc13ef429b444301a912e

am: edc2fedb  -s ours

Change-Id: I956d5f593844db3ce9d8052a8c40c0ac14b64abc

am: 3c46d2ff  -s ours

Change-Id: I888bd469644077ccc1faec52e00134027f067eef

am: b0e13e81

Change-Id: If711595a894ad6c70f8d4df1ad5f76ad4a9ab50c

am: c78db706

Change-Id: I7b866f588980ebb068629e326155976629bf2223

am: 34b76844

Change-Id: Ibe76d1cecd92f46306faf2587d229dbfc4def199

am: 224b4eac

Change-Id: I2b9ef653a1d4b21661fb07a1634b2e8af75c826b

Bluetooth needs the capability to set audio-related threads to be RT
scheduled.  Grant it sys_nice.

system_server needs to set priority for the Bluetooth HAL.  Allow it.

Bug 37518404
Test:  Play Bluetooth audio, confirm RT scheduling with systrace
Merged-In: Iaf7b85a11a51883744d72a50addfd320b6fbbc2f
Change-Id: Iaf7b85a11a51883744d72a50addfd320b6fbbc2f

(cherry picked from commit 6eee6eb2)

The fuse_device neverallow rules are too aggressive and are inhibiting
certain vendor customizations. Relax the /dev/fuse neverallow rules so
that they better reflect the security invariants we want to uphold.

Bug: 37496487
Test: policy compiles.
Change-Id: Ie73b0ba7c76446afc2a7a23ebed1275c977d932d

These were missing when the sepolicy was migrated.

Addresses denials:

E SELinux : avc:  denied  { find } for service=drm.drmManager pid=11769
uid=10018 scontext=u:r:mediaprovider:s0:c512,c768
tcontext=u:object_r:drmserver_service:s0 tclass=service_manager

W kworker/u16:2: type=1400 audit(0.0:1667): avc: denied { use } for
path="/storage/emulated/0/DCIM/Camera/IMG_20170425_124723.jpg"
dev="sdcardfs" ino=1032250 scontext=u:r:kernel:s0
tcontext=u:r:mediaprovider:s0:c512,c768 tclass=fd permissive=0

Bug: 37685394
Bug: 37686255
Test: Sync files
Test: Open downloaded file

Change-Id: Ibb02d233720b8510c3eec0463b8909fcc5bbb73d

am: a5647da3

Change-Id: I502e43626fd430da68f2a149704dafac024b3cc9

Merge "Allow Bluetooth sys_nice and system_server setsched for Bluetooth HAL" am: 2e8b0004 am: 1cc029ea
am: 1d4bb3ac

Change-Id: I319a76a77cab5f4af2f8eb98aaaa2752564e04b0

am: 1cc029ea

Change-Id: I4dc969584352c3181c3a0e49c90dff8a89940ea8

am: 2e8b0004

Change-Id: I2e8648728c5e63037686981c154d16c3010ac095

am: a9d7b895

Change-Id: I040a1874e3a08510d9b7c9a107a149845dd1976c

am: 26564ce7

Change-Id: I8961e581bad56f118c112f6b1e6d2ba11a81ccf6

am: f033cfdc

Change-Id: I8d8c0e786bdbb7374fa4a77649507706176b28d9

Test: manual
Bug: 37640900
Change-Id: I6987d60c1eb1578134b51f4e7417700fd462ba4d
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>

am: 364644eb

Change-Id: I83410880ad404a5cabd5d7ec287f5d538110556e

Empty typeset is not an issue in neverallow rules. The reason is that
it's completly normal for scontext or tcontext of neverallow rules to
evaluate to an empty type set. For example, there are neverallow rules
whose purpose is to test that all types with particular powers are
associated with a particular attribute:
  neverallow {
    untrusted_app_all
    -untrusted_app
    -untrusted_app_25
  } domain:process fork;

Test: sepolicy-analyze neverallow -w -n \
          'neverallow {} {}:binder call;'
      produces empty output instead of "Warning!  Empty type set"
Bug: 37357742
Change-Id: Id61b4fe22fafaf0522d8769dd4e23dfde6cd9f45

Test: gts-tradefed run gts -m GtsMediaTestCases -t com.google.android.media.gts.MediaPlayerTest#testLLAMA_H264_BASELINE_240P_800_DOWNLOADED_V0_SYNC

bug:37548390
Change-Id: I9c2d446118d3a5f729730b75ec117954e383159b

This adds neverallow rules which enforce the prohibition on
communication between framework and vendor components over VendorBinder.
This prohibition is similar in spirit to the one for Binder
communications.

Most changes consist of adding neverallow rules, which do not affect
runtime behavior. The only change which does affect runtime behavior
is the change which takes away the right of servicemanager domain to
transfer Binder tokens to hwservicemanager and vndservicemanager. This
grant was there by accident (because it was overly broad) and is not
expected to be needed: servicemanager, hwservicemanager, and
vndservicemanager are not supposed to be communicating with each
other.

P. S. The new neverallow rules in app_neverallows.te are covered by
the new rules in domain.te. The rules were nevertheless added to
app_neverallows.te for consistency with other *Binder rules there.

Test: mmm system/sepolicy
Bug: 37663632
Change-Id: I7c2ae23924bf0f2fed3f1e3a8d4d603129286329