Commit 619c1ef2 ("tun_device: enforce
ioctl restrictions") completely removed the ability of untrusted apps to
issue ioctl calls to tun_device. It turns out that this was too
aggressive. Wireshark apparently uses the TUNGETIFF ioctl.

Fixes the following denial:

audit(0.0:384744): avc: denied { ioctl } for comm=4173796E635461736B202332 path="/dev/tun" dev="tmpfs" ino=19560 ioctlcmd=54d2 scontext=u:r:untrusted_app:s0:c51,c257,c512,c768 tcontext=u:object_r:tun_device:s0 tclass=chr_file permissive=1 app=com.wireguard.android

Test: policy compiles.
Change-Id: I71bb494036ea692781c00af37580748ab39d1332

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

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

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

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

Bug: 118747482

Change-Id: Ie4deed90597b412ccb0e9e6512ffed2acead82d8

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

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

These /dev nodes are device-specific and should be labeled from device
policy. Moreover, pixels don't have these /dev nodes.

Bug: 110962171
Test: boot pixel 3
Change-Id: I37ca9a956130eb4763c75f5e8a0decbd4f7b97a7

As b/116344577 is fixed, we no longer need the compatbility mapping any
more.

Test: build passed. Boot succeeded.
Change-Id: I0d7f02c59853d34bdabaad6841d87e9ca1ee25d7

Bug: 111276913
Test: manual verification

Change-Id: Icb309bb07e4e4b39cdc912b1d3dc1ece9cb55f5f

A sysprop apexd.status is set by apexd, to that other components (i.e.
init) can determine whether APEXs are all successfully mounted or no
(i.e., being mounted).

The sysprop is only writable by apexd.

Bug: 117403679
Test: adb shell getprop apexd.status returns 'ready'.
Change-Id: I81bcb96e6c5cb9d899f29ffa84f91eab3820be25

Update access_vectors to support newer kernel functionality.
This change does not grant any new access.

Inspired by the following refpolicy commits:
* https://github.com/SELinuxProject/refpolicy/commit/25a5b2427447eb14edb07ce302217d37528813bc
* https://github.com/SELinuxProject/refpolicy/commit/109ab3296bce27281c453617d3629a238f5e4dbf
* https://github.com/SELinuxProject/refpolicy/commit/437e48ac53307e1e2e13e49d349c0a09b12eb187

Bug: 118843234
Test: policy compiles
Change-Id: I7c5a8dcf288dc2321adcf368bd0c0573c5257202

Require all SELinux domains which have permission to perform ioctls on
/dev/tun explicitly specify what ioctls they perform. Only allow the
safe defaults FIOCLEX and FIONCLEX, which are alternate, uncommon ways
to set and unset the O_CLOEXEC flag.

Remove app's ability to issue *any* ioctls on /dev/tun, period. Add
neverallow assertions (compile time assertion + CTS test) to prevent
regressions.

Limit system_server's ability to perform ioctls on /dev/tun to FIOCLEX,
FIONCLEX, TUNGETIFF, and TUNSETIFF. Testing and source code examination
shows that only TUNGETIFF and TUNSETIFF are used by system_server.

The goal of this change is to put SELinux ioctl controls in place for
/dev/tun, so we don't have to maintain the custom kernel patch at
https://android.googlesource.com/kernel/common/+/11cee2be0c2062ba88f04eb51196506f870a3b5d%5E%21

Delete the neverallow assertion in isolated_app.te. This is already
covered by the assertion present in app_neverallows.te.

Test: cts-tradefed run cts -m CtsHostsideNetworkTests -t com.android.cts.net.HostsideVpnTests
Test: cts-tradefed run cts -m CtsHostsideNetworkTests
Test: cts-tradefed run cts -m CtsNetTestCases
Bug: 111560739
Bug: 111560570
Change-Id: Ibe1c3a9e880db0bee438535554abdbc6d84eec45

Test: manual on device
Change-Id: Ibafe1b345489c88a49a7ed3e2e61e5cc5e1880a1

Kernel commit 3ba4bf5f1e2c ("selinux: add a map permission check for mmap")
added a map permission check on mmap so that we can
distinguish memory mapped access (since it has different implications
for revocation). system/sepolicy commit
4397f082 introduced the permission to
Android and updated common macros. Since then, we've been adding more
mmap support where it was accidentally omitted.

Add the ability for isolated_apps to mmap() app data files. There's no
reason why this should be blocked. Also fixup sdcard access which has
similar problems.

Bug: 118760652
Bug: https://crbug.com/892014
Test: policy compiles.
Change-Id: I3823f313103c9dcedf3b21d081a22f8fbb271c02

Create a transient SELinux domain where system_server can perform
certain JIT setup. The idea is that system_server will start in the
system_server_startup domain, setup certain JIT pages, then perform a
one-way transition into the system_server domain. From that point,
further JITing operations are disallowed.

Bug: 62356545
Test: device boots, no permission errors
Change-Id: Ic55b2cc5aba420ebcf62736622e08881a4779004

This reverts commit 0dd738d8.

Reason for revert: CtsSimpleperfTestCases CTS test case failures.
See b/118704604 for details.

Bug: 112357170
Bug: 118704604
Change-Id: Ibe921f3bbc3404694542ef695883c1a30777d68b

This reverts commit 67ed4328.

Reason for revert: Broken CTS test. See b/118642091

Bug: 118642091
Bug: 110379912
Change-Id: I5afd16bf23149c74f2740720cdd248a255ff1497

untrusted_app: Remove the ability to run execve() on files within an
application's home directory. Executing code from a writable /home
directory is a W^X violation (https://en.wikipedia.org/wiki/W%5EX).
Additionally, loading code from application home directories violates a
security requirement that all executable code mapped into memory must
come from signed sources, or be derived from signed sources.

Note: this change does *not* remove the ability to load executable code
through other mechanisms, such as mmap(PROT_EXEC) of a file descriptor
from the app's home directory. In particular, functionality like
dlopen() on files in an app's home directory continues to work even
after this change.

untrusted_app_25 and untrusted_app_27: For backwards compatibility,
continue to allow these domains to execve() files from the
application's home directory.

seapp_contexts: Bump the minimum API level required to enter the
untrusted_app domain. This will run API level 27-28 processes in
the API level 27 sandbox. API level 28 will continue to run with
levelFrom=all, and API level 27 will continue to run with
levelFrom=user.

Bug: 112357170
Test: Device boots and no obvious problems.
Test: See CTS test at https://android-review.googlesource.com/c/platform/cts/+/804228
Change-Id: Ief9ae3a227d16ab5792f43bacbb577c1e70185a0

system/sepolicy commit 23c9d91b
introduced a new type called privapp_data_file. This type is used to
label priv-app's /home files. For backwards compatibility, priv-app
rules involving normal app_data_files were preserved. Subsequently,
system/sepolicy commit 5d175519
assigned the file label privapp_data_file to /home files owned
by priv-apps.

Because of the previous labeling of priv-app data files, priv-apps were
granted the ability to mmap(PROT_EXEC) any other app's /home files,
regardless of how trustworthy or untrustworthy those files were. Commit
23c9d91b preserved the status quo.
However, now that we have a more refined label for priv-app /home files,
we no longer need to be as permissive.

Drop the ability for priv-apps to map executable code from
untrusted_apps home directories. "execute" is removed in this change,
and "execute_no_trans" was previously removed in commit
8fb4cb8b. Add a neverallow assertion
(compile time assertion + CTS test) to prevent regressions.

Further clarify why we need to support priv-apps loading executable code
from their own home directories, at least for now. b/112037137 covers
further tightening we can do in this area.

Bug: 112357170
Test: Device boots and no problems.
Change-Id: Ia6a9eb4c2ed8a02ad45644d025181ba3c8424cda

The current rule is missing mmap. r_file_perm implicitly adds mmap, so
we should just use that instead.

Test: policy compiles.
Change-Id: I4051d1eb4c36a2b6ff2b5f26ce53355287cbe2b4

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: I4731a8ec846c5cb84ec4b680d51938494e8ddd75

Remove blanket coredomain access to same_process_hal_file in favor of
granular access. This change takes into account audits from go/sedenials
(our internal dogfood program)

Bug: 37211678
Test: m selinux_policy
Change-Id: I5634fb65c72d13007e40c131a600585a05b8c4b5

apexd is using following additional ioctl cmds to mount the mini
filesystem inside APEXs:

 LOOP_SET_STATUS64
 LOOP_SET_FD
 LOOP_SET_BLOCK_SIZE
 LOOP_SET_DIRECT_IO
 LOOP_CLR_FD

Test: m; m apex.test; adb push <the_built_apex> /data/apex; adb reboot

/apex/com.android.example.apex exists

Change-Id: I68388cc4f323e4fcff370c8cdc0958cbd827e9cc

/dev/tegra.* is not used in android platform and is device-specific

Bug: 110962171
Test: boot walleye
Change-Id: I4cc790d28457b429a3ed9829de223dae357eb498

Bug: 118124442
Test: device can boot with android.frameworks.bufferhub@1.0-service
      running
Change-Id: I1d186d5350671b0d2dd4e831429b8fba828316e0

I found these with the regex (?<!\\)\.(?!\*|\+)

Test: make
Change-Id: I1c2e817d164b1074cb359cdb6d46bcf71e220765

Historically, vendor-init-actionable was created since the various
property_contexts files were not yet available when init parses its
scripts.  Since then, the property_contexts files are now always
available when init parses its scripts, so we can collapse these two
categories.

Specifically, this change ensures that all of the properties in the
previous 'stable_properties.h' file in init, which contained the
vendor-init-actionable properties, are able to be read by init
according to SEPolicy.

Bug: 71814576
Test: vendor_init fails to use non-readable properties as a trigger
Test: vendor_init successfully uses readable properties as a trigger

Change-Id: Ic6d9919b6047f3076a1a19fc26295c6a77aca627