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

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

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

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

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

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

See aosp/660242 and aosp/608396

Fixes: 116530289

Test: builds
Change-Id: I220ece0d6751839fe764ff91fd7bd20c50104f8f

Test: built, flashed, booted
      Clatd works well
Bug: 119006129

Change-Id: Ie3b2a7b44040755787787ff2b8e6199cac7aec8e

Bug: 111243627
Test: m selinux_policy
Change-Id: I37d03906b93c8810f1d33af736f19fd6ab241c35

Bug: 111276913
Test: manual verification

Change-Id: Icb309bb07e4e4b39cdc912b1d3dc1ece9cb55f5f

Mark the ADB service as a system_api_service so that SystemUI can tell
it that the device is accepted. Refactoring split the AdbService out of
the UsbService. UsbService is marked as an app_api_service which SystemUI
is allowed to connect to; AdbService must be marked similarly as either
system_api_service or app_api_service. However, only system apps should
talk to AdbService currently.

SELinux : avc:  denied  { find } for service=adb pid=1737 uid=10041 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:adb_service:s0 tclass=service_manager permissive=0

Introduced in Change-Id Ibf23964665a115a5bc835820dcff98aaf7ba610f

Test: Flash userdebug, accept ADB key, and replug USB
Bug: 118999282
Change-Id: I47b5090908ed84d0ba7a9fca100b299011bf8796

Allow sgdisk to force the kernel to re-read the partition table.

Addresses the following denial:

avc: denied { ioctl } for path=/dev/block/vold/disk:7,0 dev=tmpfs ino=710640 ioctlcmd=125f scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=0

Bug: 118890056
Test: policy compiles
Test:
  1) adb shell sm set-force-adoptable on
  2) adb shell sm set-virtual-disk true
  3) On device, pick the drop-down notification and
     choose "use as phone/internal storage" to adopt the virtual SD card.
Change-Id: I6825cf526cc48aa2a17afab14eadb6134bfc56f9

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

Add support for the HDIO_GETGEO and BLKGETSIZE ioctls when operating on
/dev/block/vold/ block devices.

HDIO_GETGEO is needed by the sgdisk code to get the number of heads on
the disk drive, likely a side effect of the age of this code.
https://android.googlesource.com/platform/external/gptfdisk/+/646af625ced09e5d81e07fe8c02c32017e3cbc07/diskio-unix.cc#193

Addresses the following denial:
  audit(0.0:1775): avc: denied { ioctl } for comm="sgdisk" path="/dev/block/vold/disk:8,96" dev="tmpfs" ino=10740855 ioctlcmd=0x301 scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=0

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. Technically we don't need to grant this, as the sgdisk code will
fall back to using BLKGETSIZE64 if BLKGETSIZE fails.
https://android.googlesource.com/platform/external/gptfdisk/+/646af625ced09e5d81e07fe8c02c32017e3cbc07/diskio-unix.cc#430

Addresses the following denial:
  audit(0.0:1778): avc: denied { ioctl } for comm="sgdisk" path="/dev/block/vold/disk:8,96" dev="tmpfs" ino=10740855 ioctlcmd=0x1260 scontext=u:r:sgdisk:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=0

Test: policy compiles.
Change-Id: Iaa5274721e8a7d1741591570e9e5305723aad640

Already has permissions to remove the scratch partition, but to allow
more refined cleansing (eg: just remove vendor override), need the
ability to mount and scrub overlay directories.

Test: manual
Bug: 117605276
Change-Id: Ibc272c0aa7ce207280023912f5f119ccf5079a7f

Test: manual on device
Change-Id: Ibafe1b345489c88a49a7ed3e2e61e5cc5e1880a1

Vendor need to hook bugreport propery as well as dumpstatez.
This CL exports it.

Test: Confirmed verndor can get property trigger hook manually
Bug: 118718191
Change-Id: I64a0e38716fb863ccd8923c6c41a776ea341f2d1
Signed-off-by: Minchan Kim <minchan@google.com>

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

These ioctls are similar to BLKGETSIZE64; they return benign information
about the partition's alignment, and are used by liblp to optimally
align dynamic partition extents.

The system_block_device is included here because on retrofit devices,
the "super" partition is mapped to the system partition.

Bug: 116802789
Test: fastboot flashall
Change-Id: I38282904828105cf5f16ce9d4b5884d2b0e89d38

This reverts commit 67ed4328.

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

Bug: 118642091
Bug: 110379912
Change-Id: I5afd16bf23149c74f2740720cdd248a255ff1497

Update the "allowxperm" to reflect the various ioctl() performed in
the vold source code.

Bug: 118437832
Test: atest android.os.storage.cts.StorageManagerTest
Change-Id: Ide3a09104d8b4ce7fa2b7e23e9b215139186f595

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

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

Added a new flag to specify the IWLAN operation mode. Also
allowed this system properties for vendor native service to
access.

Test: Manual
Bug: 73659459
Change-Id: I23197e451557fae36a0cc5da4b50b3a00f9233dc

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

update_engine does a lot to keep partitions secure and tidy. Allow the
ioctls necessary to allow that to happen.

Addresses the following denials:

update_engine: type=1400 audit(0.0:6): avc: denied { ioctl } for path="/dev/block/sda20" dev="tmpfs" ino=13850 ioctlcmd=1277 scontext=u:r:update_engine:s0 tcontext=u:object_r:boot_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:8): avc: denied { ioctl } for path="/dev/block/sda20" dev="tmpfs" ino=13850 ioctlcmd=127c scontext=u:r:update_engine:s0 tcontext=u:object_r:boot_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:9): avc: denied { ioctl } for path="/dev/block/sda20" dev="tmpfs" ino=13850 ioctlcmd=127f scontext=u:r:update_engine:s0 tcontext=u:object_r:boot_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:13): avc: denied { ioctl } for path="/dev/block/sda18" dev="tmpfs" ino=12601 ioctlcmd=127d scontext=u:r:update_engine:s0 tcontext=u:object_r:custom_ab_block_device:s0 tclass=blk_file permissive=0

Bug: 118319505
Test: policy compiles.
Change-Id: I424f2a13ced2324b4c0c35b0f510b9aea748d5aa

Update engine is responsible for updating various partitions, which
includes enabling or disabling the read-only bit on the underlying block
device.

Rather than try to list out each block device separately, generalize the
ioctl rules to apply to all block device nodes. If the ioctl permission
is granted via a normal allow rule, then the allowxperm statement will
allow BLKROGET and BLKROSET by default on those block devices.

Test: policy compiles
Bug: 118150702
Change-Id: I7bca52e0f442df7320748f6d6371e5016aa6dd0b

vold needs to securely delete content from various block devices. Allow
it.

Addresses the following denials:

type=1400 audit(0.0:66): avc: denied { ioctl } for comm="secdiscard" path="/dev/block/dm-3" dev="tmpfs" ino=17945 ioctlcmd=0x127d scontext=u:r:vold:s0 tcontext=u:object_r:dm_device:s0 tclass=blk_file permissive=0
type=1400 audit(0.0:43): avc: denied { ioctl } for comm="secdiscard" path="/dev/block/sda45" dev="tmpfs" ino=17485 ioctlcmd=127d scontext=u:r:vold:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file permissive=0

Test: policy compiles.
Change-Id: Ie7b4b8ac4698d9002a4e8d142d4e463f8d42899a

Bug: 118161817
Test: SANITIZE_TARGET=address m selinux_policy
Change-Id: I4dabcb3692c59b810a06567e272bca9f0e9c3ecd

This prevents denials while taking a bugreport.

Test: cts-tradefed run cts -m CtsSecurityHostTestCases -t
android.security.cts.SELinuxHostTest#testNoBugreportDenials

Change-Id: I381b39fa127f82fcef5d820a04209fd1ba4f63cd

Allow BLKROGET and BLKROSET on the block devices underlying the /system
and rootfs partitions. As part of the Android boot process, the system
sets the block devices read-only to prevent accidental modification to
these partitions. Update engine needs the ability to adjust the block
device read-only flag in order to apply updates.

Addresses the following denials:

update_engine: type=1400 audit(0.0:96): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125e scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:97): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125d scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0

Test: policy compiles
Bug: 118150702
Change-Id: I65a3d041b6d6b7955bcd901637a543524fc34a06

system/sepolicy commit 4c8eaba7, reviewed in
https://android-review.googlesource.com/c/platform/system/sepolicy/+/793958
started enforcing explicit ioctl permission checks for all block device
files. As part of that commit, the following lines were added to
domain.te:

  # If a domain has access to perform an ioctl on a block device, allow these
  # very common, benign ioctls
  allowxperm domain dev_type:blk_file ioctl { BLKGETSIZE64 BLKSSZGET };

In essence, if a domain is granted ioctl access to any device in
policy (for example, via adding "ioctl" to the allow rule, or by using
the macro "r_file_perms" which includes the ioctl permission), then the
two ioctls BLKGETSIZE64 and BLKSSZGET will be automatically allowed. As
such, it is redundent for a domain to explicitly request these two
ioctls.

Delete the now redundant allowxperm rule.

Test: policy compiles
Change-Id: I1964ed93a7c7601393cc9e2416f3640ea22db51b