This reverts commit 0dd738d8.

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

Bug: 112357170
Bug: 118704604
Change-Id: Ibe921f3bbc3404694542ef695883c1a30777d68b

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

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

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

Change-Id: I7a398025c18a7ce22c775a67328dc5504f98c04f

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

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

Bug: 113136846
Test: manual
Change-Id: I5c515ca4eafb39c4c3d04b3e736471ae38d38545

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

Bug: 118185801
Test: bug no. appears in the denial logs
Change-Id: Ib1d1bbbdf25e0e63ac8a7dec98aca08cafc3f870

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

Copied from device/google/crosshatch-sepolicy.

Test: diff files in system/etc/selinux before and after for aosp_marlin
Change-Id: I518c43af9c217483bdab02424e4aef0270aad366

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

This is used to address a CTS testcase failure. This CTS
testcase need to access the content of Contact, some data
from ContactProvider is transfered through ashmem.

Currently ashmem is backed by the tmpfs filesystem, ContactProvider
in android run as a priv_app, so the file context of the ashmem
created by ContactProvider is priv_app_tmpfs. CTS runs as an
untrusted_app, need to be granted the read permission to the
priv_app_tmpfs files.

Bug: 117961216

[Android Version]:
android_p_mr0_r0

[Kernel Version]:
4.19.0-rc8

[CTS Version]:
cts-9.0_r1

[Failed Testcase]:
com.android.cts.devicepolicy.ManagedProfileTest#testManagedContactsPolicies

[Error Log]:
11-11 11:15:50.479 12611 12611 W AndroidTestSuit: type=1400 audit(0.0:811):
avc: denied { read } for path=2F6465762F6173686D656D202864656C6574656429
dev="tmpfs" ino=174636 scontext=u:r:untrusted_app:s0:c113,c256,c522,c768
tcontext=u:object_r:priv_app_tmpfs:s0:c522,c768 tclass=file permissive=0

[Test Result With This Patch]:
PASS

Change-Id: I45efacabe64af36912a53df60ac059889fde1629

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

What changed:
- Tightening neverallow forbidding vendor execution access in /system.
In it's current form the neverallow is loose because not all executables
have exec_type attribute, e.g. almost everything in /system/bin/. This
change tightens up the neverallow by instead targeting system_file_type
attribute, which must be applied to all files in /system.
- Adding a general neverallow forbidding all access to files in /system
(bar exceptions)

TODOs:
- Remove loopholes once Treble violations are fixed across all internal
build targets.

Bug: 111243627
Test: m selinux_policy; build-only change
Change-Id: I150195756c0c3258904c3da0812bbd942ea2f229