BLKDISCARD is used by vold while wiping block devices
https://android.googlesource.com/platform/system/vold/+/b2455747a92957d109a050b8f3e394d87d085086/Utils.cpp#619

BLKGETSIZE is used to determine the size of the block device. Ideally
code should not be using this ioctl, as it fails for devices >= 2T in
size. Vold indirectly uses this when executing /system/bin/newfs_msdos.
Arguably this is a bug in newfs_msdos, as BLKGETSIZE64 should be used
instead.
Code: https://android.googlesource.com/platform/external/newfs_msdos/+/0c7e133c7fde67911efb7bd920d4f0ab0c269af8/mkfs_msdos.c#845

Addresses the following denials:

audit(0.0:24): avc: denied { ioctl } for comm="Binder:588_2" path="/dev/block/vold/public:7,9" dev="tmpfs" ino=106407 ioctlcmd=1277 scontext=u:r:vold:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=0
audit(0.0:25): avc: denied { ioctl } for comm="newfs_msdos" path="/dev/block/vold/public:7,9" dev="tmpfs" ino=106407 ioctlcmd=1260 scontext=u:r:vold:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=0

Test: policy compiles.
Bug: 119562530
Change-Id: Ib7198daf150d6f2578545a6a402e0313069ea2b4

This enables native wireless interface configuration at boot.

Bug: 36120314
Test: adb shell ifconfig -a | grep wlan
Change-Id: I797c0c8a8645d690d311f42cec3998b2f4cee77b

Test: m
Test: flash sailfish
Test: profile system_server

Change-Id: I577793af655146ee91be86bb286fcf9d6e6d081d

It will not end when other words appeared because of the wrong bound and variable,
rule_map->length will exceed the actual length in the rule_map_new function,
it will lead to crash in the rule_map_validate function because of strcmp(NULL, str).

Test: 1.add "user=shell doman=system_app" to private/seapp_contexts
      2.exec "checkseapp private/seapp_contexts" and it will not be crashed

Change-Id: I600206448b38cf2c9b61f9141b40f920b05696c8
Signed-off-by: liwugang <liwugang@xiaomi.com>

We are moving AppFuse mount from system_server's mount namespace to
vold. Hence, we could reduce the SELinux permissions given to
system_server, in the expense of adding allow rules to vold and
letting appdomain have access to vold's fd.

Bug: 110379912
Test: testOpenProxyFileDescriptor passes (after vold and
system_server code changes)

Change-Id: I827a108bd118090542354360a8c90b295e6a0fef

For centralized development of sepolices, file_contexts files for APEXes
are all moved to under /system/seplicy.

Bug: 119034475
Bug: 113373927
Test: m apex.test com.android.tzdata com.android.runtime com.android.media
Change-Id: I9bf4874793db4dbdb75cbd759ae95f72d7281007

He's already listed as an authorized +2er in
https://android-review.googlesource.com/admin/groups/810,members

Test: none
Change-Id: Ifff6b3f8353d562b3386d0c2e3b575154f173e23

mtd_device does not label any /dev node present on walleye, and the only
permission to that type is:
allow hal_telephony_server mtd_device:dir search;
I suspect there is no need to keep mtd_device around.

Bug: 110962171
Test: boot aosp_walleye
Change-Id: If74b1258b21edeca38c8b7dc07a3a10b751a7e85

Test: ensure no build failures;
add RoleManagerService as a boot phase
ensure no SecurityException in logcat on boot
Change-Id: Ia0803c0fb084fe2b12f5c20f5e46354d0dd1aedf

system/sepolicy commit 619c1ef2 started
enforcing ioctl whitelisting requirements for /dev/tun. Bluetooth needs
the ability to issue TUNSETIFF on /dev/tun, so allow access. We also
allow access to TUNGETIFF for good measure.

Addresses the following denial:

avc: denied { ioctl } for comm=425420536572766963652043616C6C path="/dev/tun" dev="tmpfs" ino=20047 ioctlcmd=0x54ca scontext=u:r:bluetooth:s0 tcontext=u:object_r:tun_device:s0 tclass=chr_file permissive=0

Test: policy compiles
Change-Id: Ie4c138fc774373cec266c59de6663db147d60423

No coredomain domain has access to these types and corresponding /dev
nodes don't exist on the device:

audio_seq_device
audio_timer_device
full_device
i2c_device
vcs_device

Bug: 110962171
Test: m selinux_policy
Test: boot walleye
Change-Id: I89ad4755e6760aa166cb22e2655567e5905dc672

Test: m -j succeeded and manual tested on device

Change-Id: I3415c58335361a9da4ef2368e61bc4e0250a91bb

These rules mirror those for /vendor/overlay and /odm/overlay, including
the possilibity of a symlink like /system/vendor -> /vendor.

Test: builds, boots
Change-Id: I323e48fcc13c4ac7779902506539c2600708cc88

Historically GPU service lives in SurfaceFlinger as a convenient hack.
Howerver, SurfaceFlinger doesn't need to know about anything specific about GPU
capability, and shouldn't know about anything about GPU. This patch moves GPU
service out of SurfaceFlinger.

GPU service is a service that accesses to GPU driver, queries GPU capabilities
and reports back. Currently we use this information in CTS and some benchmarks.

BUG: 118347356
Test: Build, flash and boot, use `adb shell cmd gpu vkjson` to verify
Change-Id: I007989e0f3f73b5caf80277979986820dd127c32

* changes:
  Add runas_app domain to allow running app data file via run-as.
  Revert "Revert "Enforce execve() restrictions for API > 28""

This is useful to test how it would behave on devices with user builds.

Bug: 117980186
Test: adb shell setprop dumpstate.unroot true && \
      adb shell cmd activity bug-report --progress

Change-Id: If9094bbe0c29e8180f1b35d2b4ac95343a1bd0eb

This allows to use adb pull on Perfetto traces on user.

Bug: 118747482

Change-Id: Ie4deed90597b412ccb0e9e6512ffed2acead82d8

* changes:
  Allow apexd to configure /sys/block/dm-
  Allow the kernel to access apexd file descriptors.

To configure readahead for APEX dm-verity devices.

Bug: 117823094
Test: apexd can change readahead
Change-Id: Ie0396d59ef758ad55f499f65957697d26a48aae9

In earlier kernel versions (<4.0), the loopback driver issues
requests from a kernel thread. Therefore, the kernel needs access
to APEX file descriptors and data files (which are loopback
mounted).

Bug: 119220815
Test: mounting works on sailfish
Change-Id: I75b2bade41c64cf6fa6040d9c2f5489a206e04c6

apexd_prop is also defined in private/propery_contexts in order to make
the type to exist even when PRODUCT_COMPATIBLE_PROPERTY is false (i.e.,
Pixel 1).

Bug: 119220815
Test: m plat_property_contexts for sailfish
the built plat_property_contexts has apexd_prop defined

Change-Id: I9ef71410533c1f64fc6a3112cfcb199d23aaf3db

Pass LOCAL_ADDITIONAL_M4DEFS to m4 when building vendor_file_contexts
and odm_file_contexts. The build command attempts to use
PRIVATE_ADDITIONAL_M4DEFS - but this is not set in the target-specific
variables.

This allows using custom M4 macros when building non-platform
file_contexts.

Change-Id: I5fa8d9ec91f1a97bee1dd735ba85af93eef91252

See aosp/660242 and aosp/608396

Fixes: 116530289

Test: builds
Change-Id: I220ece0d6751839fe764ff91fd7bd20c50104f8f

Test: build passed.
Bug: 118614333
Change-Id: I3b33d73a2cc7e78119de8b0913b4e2d0ac4a3235

Calling execve() on files in an app's home directory isn't allowed
for targetApi >=29. But this is needed by simpleperf to profile
a debuggable app via run-as.
So workaround it by adding runas_app domain, which allows running
app data file. And add a rule in seapp_contexts to use runas_app
domain for setcontext requests from run-as.

Bug: 118737210
Test: boot marlin and run CtsSimpleperfTestCases.
Change-Id: I5c3b54c95337d6d8192861757b858708174ebfd5

This reverts commit 15d1a12f.

Bug: 118737210
Bug: 112357170
Test: boot marlin
Change-Id: Idcfab04b48f843eead4efa9f58a1337c6685c6ca