Remove kernel attack surface associated with ioctls on plain files. In
particular, we want to ensure that the ioctls FS_IOC_ENABLE_VERITY and
FS_IOC_MEASURE_VERITY are not exposed outside a whitelisted set of
entities. However, it's straight forward enough to turn on ioctl
whitelisting for everything, so we choose to do so.

Test: policy compiles and device boots
Test: device boots with data wipe
Test: device boots without data wipe
Change-Id: I545ae76dddaa2193890eeb1d404db79d1ffa13c2

This daemon is very locked down. Only system_server can access it.

Bug: 72170747
Change-Id: I7b72b9191cb192be96001d84d067c28292c9688f

This fixes a build breakage.

Test: Build policy.
Change-Id: Id5209a2bd6446ac6dd744b7426f540bc1a8641ed

Allows checkpoint commands to check A/B update status

Test: vdc checkpoint startCheckpoint -1
Bug: 111020314
Change-Id: I086db548d55176bf88211001c7c1eecb8c50689e

system_file_type is a new attribute used to identify files which exist
on the /system partition. It's useful for allow rules in init, which are
based off of a blacklist of writable files. Additionally, it's useful
for constructing neverallow rules to prevent regressions.

Additionally, add commented out tests which enforce that all files on
the /system partition have the system_file_type attribute. These tests
will be uncommented in a future change after all the device-specific
policies are cleaned up.

Test: Device boots and no obvious problems.
Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5

Assert that only apps and installd may open private app files.

Remove "open" permission for mediaserver/vold and remove their
neverallow exemption.

Test: verify no related audit messages in the logs.
Test: build
Fixes: 80300620
Fixes: 80418809
Bug: 80190017
Change-Id: If0c1862a273af1fedd8898f334c9b0aa6b9be728

...to reflect that the HAL operates on storage devices,
not filesystem.

Bug: 111655771
Test: compiles
Change-Id: Ibb0572cb1878359e5944aa6711331f0c7993ba6e
Merged-In: Ibb0572cb1878359e5944aa6711331f0c7993ba6e

kernel commit 2a4c22426955d4fc04069811997b7390c0fb858e (fs: switch order
of CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH checks) swapped the order of
dac_override and dac_read_search checks.  Domains that have dac_override
will now generate spurious denials for dac_read_search unless they also
have that permission.  Since dac_override is a strict superset of
dac_read_search, grant dac_read_search to all domains that already have
dac_override to get rid of the denials.

Bug: 114280985
Bug: crbug.com/877588
Test: Booted on a device running 4.14.
Change-Id: I5c1c136b775cceeb7f170e139e8d4279e73267a4

Bug: 78888165
Test: device can boot with HAL running.
Change-Id: I3bf7c8203e038b892176c97ec006152a2904c7be

Bug: 111655771
Test: builds
Change-Id: I67850d910770109005b2243c628282ad638c88fb

Bug: 111890351
Test: Device boots and no selinux denials when vold mounts
      at /mnt/user/.*

Change-Id: Id962a85af9f99c54421f0820a22880be36c2e478

Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.

This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.

This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:

  -user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
  +user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user

For now, this newly introduced label has no usage, so this change
is essentially a no-op.

Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
      filesystem upgrade.

Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837

vold will trim rw mount points about daily, but it is denied by SELinux:

root   603   603 W Binder:603_2: type=1400 audit(0.0:11): avc: denied {
search } for name="vendor" dev="tmpfs" ino=23935 scontext=u:r:vold:s0
tcontext=u:object_r:mnt_vendor_file:s0 tclass=dir permissive=0

Allowing vold to search /mnt/vendor/* to fix the denials.

Note that device-specific sepolicy needs to be extended to allow vold
to send FITRIM ioctl. e.g., for /mnt/vendor/persist, it needs:

    allow vold persist_file:dir { ioctl open read };

Bug: 111409607
Test: boot a device, checks the above denial is gone
Change-Id: Ia9f22d973e5a2e295678781de49a0f61fccd9dad

It doesn't need to read batteryinfo to function properly.
Bug: 110891415
Test: builds and boots

Change-Id: I7f388180a25101bfd0c088291ef03a9bf8ba2b2c

In particular, add assertions limiting which processes may
directly open files owned by apps. Reduce this to just apps, init,
and installd. App data is protected by a combination of selinux
permissions and Unix permissions, so limiting the open permission to
just apps (which are not allowed to have CAP_DAC_OVERRIDE or
CAP_DAC_READ_SEARCH) ensures that only installd and init have
complete access an app's private directory.

In addition to apps/init/installd, other processes currently granted
open are mediaserver, uncrypt, and vold. Uncrypt's access appears to
be deprecated (b/80299612). Uncrypt now uses /data/ota_package
instead. b/80418809 and b/80300620 track removal for vold and
mediaserver.

Test: build/boot aosp_taimen-userdebug. Verify no "granted" audit
messages in the logs.
Bug: 80190017
Bug: 80300620
Bug: 80418809
Fixes: 80299612
Change-Id: I153bc7b62294b36ccd596254a5976dd887fed046

This relaxes the neverallow rule blocking vendor_init from doing
anything to vold_metadata_file.  The rules above it still prevent it
from doing anything other than relabelto and getattr.

Bug: 79681561
Test: Boot device and see no denials.
Change-Id: I1beb25bb9f8d69323c9fee53a140c2a084b12124
(cherry picked from commit 597be44e)

This relaxes the neverallow rule blocking vendor_init from doing
anything to vold_metadata_file.  The rules above it still prevent it
from doing anything other than relabelto and getattr.

Bug: 79681561
Test: Boot device and see no denials.
Change-Id: I1beb25bb9f8d69323c9fee53a140c2a084b12124

Files in /proc/net leak information. This change is the first step in
determining which files apps may use, whitelisting benign access, and
otherwise removing access while providing safe alternative APIs.

To that end, this change:
* Introduces the proc_net_type attribute which will assigned to any
new SELinux types in /proc/net to avoid removing access to privileged
processes. These processes may be evaluated later, but are lower
priority than apps.
* Labels /proc/net/{tcp,tcp6,udp,udp6} as proc_net_vpn due to existing
use by VPN apps. This may be replaced by an alternative API.
* Audits all other proc/net access for apps.
* Audits proc/net access for other processes which are currently
granted broad read access to /proc/net but should not be including
storaged, zygote, clatd, logd, preopt2cachename and vold.

Bug: 9496886
Bug: 68016944
Test: Boot Taimen-userdebug. On both wifi and cellular: stream youtube
    navigate maps, send text message, make voice call, make video call.
    Verify no avc "granted" messages in the logs.
Test: A few VPN apps including "VPN Monster", "Turbo VPN", and
"Freighter". Verify no logspam with the current setup.
Test: atest CtsNativeNetTestCases
Test: atest netd_integration_test
Test: atest QtaguidPermissionTest
Test: atest FileSystemPermissionTest

Change-Id: I7e49f796a25cf68bc698c6c9206e24af3ae11457
Merged-In: I7e49f796a25cf68bc698c6c9206e24af3ae11457
(cherry picked from commit 08731895)

Bug: 77335096
Test: booted device with metadata encryption and without
Change-Id: I5bc5d46deb4e91912725c4887fde0c3a41c9fc91

Bug: 77335096
Test: booted device with metadata encryption and without
Change-Id: I5bc5d46deb4e91912725c4887fde0c3a41c9fc91

Restrictions introduced in vendor init mean that new devices
may not no longer exempt vendor init from writing to system_data_file.
This means we must introduce a new label for /data/vendor which
vendor_init may write to.

Bug: 73087047
Test: build and boot Taimen and Marlin. Complete SUW, enroll fingerprint
    No new denials.

Change-Id: I65f904bb28952d4776aab947515947e14befbe34

Bug: 63927601
Test: Enable metadata encryption in fstab on Taimen, check boot success.

Change-Id: Iddbcd05501d360d2adc4edf8ea7ed89816642d26

And remove a redundant rule.

Test: sesearch shows no changes to vold's sepolicy.
Change-Id: Icccc18696e98b999968ecbe0fb7862c35575a9b3

This CL lists all the exported platform properties in
private/exported_property_contexts.

Additionally accessing core_property_type from vendor components is
restricted.
Instead public_readable_property_type is used to allow vendor components
to read exported platform properties, and accessibility from
vendor_init is also specified explicitly.

Note that whitelisting would be applied only if
PRODUCT_COMPATIBLE_PROPERTY is set on.

Bug: 38146102
Test: tested on walleye with PRODUCT_COMPATIBLE_PROPERTY=true
Change-Id: I304ba428cc4ca82668fec2ddeb17c971e7ec065e

This reverts commit 640e595a. The
corresponding code in libcutils was removed, so this is now unneeded.

Bug: 71632076
Test: aosp_sailfish still works

Change-Id: I615bab83e9a83bc14439b8ab90c00d3156b0a7c4

Commit 7688161c "hal_*_(client|server) => hal(client|server)domain"
added neverallow rules on hal_*_client attributes while simultaneously
expanding these attribute which causes them to fail CTS neverallow
tests. Remove these neverallow rules as they do not impose specific
security properties that we want to enforce.

Modify Other neverallow failures which were imposed on hal_foo
attributes and should have been enforced on hal_foo_server attributes
instead.

Bug: 69566734
Test: cts-tradefed run cts -m CtsSecurityHostTestCases -t \
    android.cts.security.SELinuxNeverallowRulesTest

    CtsSecurityHostTestCases completed in 7s. 627 passed, 1 failed
    remaining failure appears to be caused by b/68133473
Test: build taimen-user/userdebug

Change-Id: I619e71529e078235ed30dc06c60e6e448310fdbc

This reverts commit ed876a5e.

Fixes user builds.
libsepol.report_failure: neverallow on line 513 of system/sepolicy/public/domain.te (or line 9149 of policy.conf) violated by allow update_verifier misc_block_device:blk_file { ioctl read write lock append open }; 
libsepol.check_assertions: 1 neverallow failures occurred 
Error while expanding policy
Bug: 69566734
Test: build taimen-user
Change-Id: I969b7539dce547f020918ddc3e17208fc98385c4

Commit 7688161c "hal_*_(client|server) => hal(client|server)domain"
added neverallow rules on hal_*_client attributes while simultaneously
expanding these attribute which causes them to fail CTS neverallow
tests. Remove these neverallow rules as they do not impose specific
security properties that we want to enforce.

Modify Other neverallow failures which were imposed on hal_foo
attributes and should have been enforced on hal_foo_server attributes
instead.

Bug: 69566734
Test: cts-tradefed run cts -m CtsSecurityHostTestCases -t \
    android.cts.security.SELinuxNeverallowRulesTest

    CtsSecurityHostTestCases completed in 7s. 627 passed, 1 failed
    remaining failure appears to be caused by b/68133473
Change-Id: I83dcb33c3a057f126428f88a90b95f3f129d9f0e

In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.

This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.

This is essentially:
  1. New global_capability_class_set and global_capability2_class_set
     that match capability+cap_userns and capability2+cap2_userns,
     respectively.
  2. s/self:capability/self:global_capability_class_set/g
  3. s/self:capability2/self:global_capability2_class_set/g
  4. Add cap_userns and cap2_userns to the existing capability_class_set
     so that it covers all capabilities.  This set was used by several
     neverallow and dontaudit rules, and I confirmed that the new
     classes are still appropriate.

Test: diff new policy against old and confirm that all new rules add
      only cap_userns or cap2_userns;
      Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831

Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f

Bug: 62378620
Test: Android in Chrome OS can call uevent_kernel_recv() and not fail
      with EIO.
Test: bullhead networking still works

Change-Id: I4dd5d2148ee1704c4fa23d7fd82d1ade19b58cbd

Bug: 25861755
Test: Boot device, create user, create files, remove user, observe logs
Change-Id: I195514eb45a99c1093998786ab385338463269c0
Merged-In: I195514eb45a99c1093998786ab385338463269c0
(cherry picked from commit eb7340d9)

Bug: 25861755
Test: Boot device, observe logs
Change-Id: I6c13430d42e9794003eb48e6ca219b874112b900
Merged-In: I6c13430d42e9794003eb48e6ca219b874112b900
(cherry picked from commit 47f3ed09)

Bug: 25861755
Test: Boot device, create user, create files, remove user, observe logs
Change-Id: I195514eb45a99c1093998786ab385338463269c0

Bug: 25861755
Test: Boot device, observe logs
Change-Id: I6c13430d42e9794003eb48e6ca219b874112b900

Prior to this CL, /sys/devices/virtual/block/dm-X was using the generic
sysfs label. This CL creates sysfs_dm label and grants the following
accesses:
 - update_verifier to read sysfs_dm dir and file at
   /sys/devices/virtual/block/dm-X.
 - vold to write sysfs_dm.

Bug: 63440407
Test: update_verifier successfully triggers blocks verification and
      marks a sucessful boot;
Test: No sysfs_dm related denials on sailfish.
Change-Id: I6349412707800f1bd3a2fb94d4fe505558400c95

On Marlin/Sailfish, StorageManager tests in CTS are exposing a bug
where the /proc/<pid>/ns/mnt files for system_server are briefly
mislabeled as "proc" instead of "system_server". Resulting in the
tests failing. Temporarily re-granting access to the default label
until the labeling issue can be tracked down.

Repro steps:
cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases \
-t android.os.storage.cts.StorageManagerTest

Failures:

android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor
fail: java.lang.IllegalStateException: command '58 appfuse mount 10065
959 0' failed with '400 58 Command failed'

android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor_async
fail: java.lang.IllegalStateException: command '59 appfuse mount 10065
959 1' failed with '400 59 Command failed'

android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor_error
fail: java.lang.IllegalStateException: command '60 appfuse mount 10065
959 2' failed with '400 60 Command failed'

From the log:

10-04 20:41:22.972   595   604 E vold    : Failed to open namespace for
/proc/959/ns/mnt: Permission denied
10-04 20:41:22.967   604   604 W vold    : type=1400 audit(0.0:90): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.051   604   604 W vold    : type=1400 audit(0.0:91): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.054   595   604 E vold    : Failed to open namespace for
/proc/959/ns/mnt: Permission denied
10-04 20:41:23.081   604   604 W vold    : type=1400 audit(0.0:92): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.086   595   604 E vold    : Failed to open namespace for
/proc/959/ns/mnt: Permission denied

sailfish:/ # ps -AZ | grep 959
u:r:system_server:s0           system         959   628 \
4557136 251500 SyS_epoll_wait 70e6df822c S system_server

The file labels appear to be correct when checked manually.

sailfish:/ # ls -lZ /proc/959/ns/
lrwxrwxrwx 1 system system u:r:system_server:s0 0 2017-10-04 17:19 mnt -> mnt:[4026534249]
lrwxrwxrwx 1 system system u:r:system_server:s0 0 2017-10-04 20:55 net -> net:[4026531906]

Bug: 67049235
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases \
    -t android.os.storage.cts.StorageManagerTes

Change-Id: Id4d200856c02c023c6f516e3f3bfa060e100086c

Bug: 37916906
Test: Builds 'n' boots.
Change-Id: Ia1d86264446ebecc1ca79f32f11354921bc77668
Merged-In: I208ec6a864127a059fb389417a9c6b259d7474cb

Bug: 37916906
Test: Builds 'n' boots.
Change-Id: Ia1d86264446ebecc1ca79f32f11354921bc77668
Merged-In: I208ec6a864127a059fb389417a9c6b259d7474cb

1. Labeled:
/proc/cmdline -> proc_cmdline

2. Removed access to proc label from vold domain.

3. Added access proc_cmdline to these domains:
init, kernel, vold

4. Also, added proc_drop_caches access to vold.

Bug: 66497047
Test: device boots without selinux denials to new labels
Change-Id: Ic88d11b7e56b07c0e8bd874e7f72788922a218e3

proc files needed by fwk that were labeled:
/proc/filesystems -> proc_filesystems
/proc/mounts -> proc_mounts
/proc/swaps -> proc_mounts

Removed access to proc label from these domains:
e2fs, fsck, fsck_untrusted, sdcardd

e2fs: added access to proc_filesystems, proc_mounts, proc_swaps
fsck: added access to proc_mounts, proc_swaps
fsck_untrusted: added access to proc_mounts
sdcardd: added access to proc_filesystems
vold: added access to proc_filesystems, proc_mounts

Bug: 66199084
Test: device boots without selinux denials to new labels or proc label.
Change-Id: If0f19e22074419dab0b3a0c6f3a300ea8cb94523