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

Use nice clean AIDL instead of dirty sockets.

avc: denied { call } for pid=603 comm="vdc" scontext=u:r:vdc:s0 tcontext=u:r:servicemanager:s0 tclass=binder permissive=0

Test: vdc cryptfs init_user0
Bug: 13758960
Change-Id: I8b0e63adad8c4c7e2b5e6aca48386d1b371ea6a5

This change is the bare minimum needed to publish a new vold
Binder service and move the simple "reset" call over to go through
the new interface.

The new rules here are mirrored on the existing installd rules, but
with a handful of neverallow rules relaxed due to funky interactions
with hal_client_domain().

Test: builds, boots
Bug: 13758960
Change-Id: Ia9522ea7a68698cb0edce7879abfbf22b9d67c76

Raw sockets usually imply advanced parsers that might
have flaws. If vold need such odd thing, force it to have
that in a other domain like filesystem checks. Debug
features like ptrace does not belong to vold.

Bug: 64791922
Test: Manual
Change-Id: I75c62d13f998621f80b2049bce0505442862bf0b

Hardening vold. Vold has much rights to system sensitive parts and
are started by init. Enforce this security.

Bug: 64791922
Test: Manual
Change-Id: I077d251d1eb7b7292e1a4a785093cb7bf5524a83

This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.

Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
      permissions.
Merged-In: I31beeb5bdf3885195310b086c1af3432dc6a349b
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b
(cherry picked from commit 76aab82c)

scontext=installd
avc: granted { getattr } for comm="Binder:1153_7" path="/data/user/0"
dev="sda13" ino=1097730 scontext=u:r:installd:s0
tcontext=u:object_r:system_data_file:s0 tclass=lnk_file

scontext=runas
avc: granted { getattr } for comm="run-as" path="/data/user/0"
dev="sda35" ino=942082 scontext=u:r:runas:s0
tcontext=u:object_r:system_data_file:s0 tclass=lnk_file

scontext=vold
avc: granted { getattr } for comm="vold" path="/data/data" dev="sda45"
ino=12 scontext=u:r:vold:s0 tcontext=u:object_r:system_data_file:s0
tclass=lnk_file
avc: granted { read } for comm="secdiscard"
name="3982c444973581d4.spblob" dev="sda45" ino=4620302
scontext=u:r:vold:s0 tcontext=u:object_r:system_data_file:s0
tclass=file

Bug: 28760354
Test: Build
Change-Id: Id16c43090675572af35f1ad9defd4c368abc906b

When adopting SD cards, vold partitions and formats those devices;
this had been working fine with the older make_ext4fs utility, but
newer devices are switching over to mke2fs, which has a different
SELinux label.

avc: denied { execute } for name="mke2fs" dev="dm-0" ino=456 scontext=u:r:vold:s0 tcontext=u:object_r:e2fs_exec:s0 tclass=file permissive=1
avc: denied { read open } for path="/system/bin/mke2fs" dev="dm-0" ino=456 scontext=u:r:vold:s0 tcontext=u:object_r:e2fs_exec:s0 tclass=file permissive=1
avc: denied { execute_no_trans } for path="/system/bin/mke2fs" dev="dm-0" ino=456 scontext=u:r:vold:s0 tcontext=u:object_r:e2fs_exec:s0 tclass=file permissive=1
avc: denied { getattr } for path="/system/bin/mke2fs" dev="dm-0" ino=456 scontext=u:r:vold:s0 tcontext=u:object_r:e2fs_exec:s0 tclass=file permissive=1

Test: cts-tradefed run commandAndExit cts-dev --abi armeabi-v7a -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Bug: 36757864, 37436961
Change-Id: Ifb96dfca076ea58650eb32f89e850f20ae2ac102

This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.

Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
      permissions.
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b

Relabeling /vendor and /system/vendor to vendor_file removed
previously granted permissions. Restore these for non-treble devices.

Addresses:
avc: denied { execute_no_trans } for pid=2944 comm="dumpstate"
path="/system/vendor/bin/wpa_cli" dev="mmcblk0p10" ino=1929
scontext=u:r:dumpstate:s0 tcontext=u:object_r:vendor_file:s0
tclass=file

And potentially some other bugs that have yet to surface.

Bug: 37105075
Test: build Fugu
Change-Id: I8e7bd9c33819bf8206f7c110cbce72366afbcef8

file_context files need to be explicitly labeled as they are now split
across system and vendor and won't have the generic world readable
'system_file' label.

Bug: 36002414
Test: no new 'file_context' denials at boot complete on sailfish
Test: successfully booted into recovery without denials and sideloaded
OTA update.
Test: ./cts-tradefed run singleCommand cts --skip-device-info \
       --skip-preconditions --skip-connectivity-check --abi \
       arm64-v8a --module CtsSecurityHostTestCases -t \
       android.security.cts.SELinuxHostTest#testAospFileContexts

Change-Id: I603157e9fa7d1de3679d41e343de397631666273
Signed-off-by: Sandeep Patil <sspatil@google.com>

This is a special file that can be mounted as a loopback device to
exercise adoptable storage code on devices that don't have valid
physical media.  For example, they may only support storage media
through a USB OTG port that is being used for an adb connection.

avc: denied { read } for path="/data/misc/vold/virtual_disk" dev="sda35" ino=508695 scontext=u:r:kernel:s0 tcontext=u:object_r:vold_data_file:s0 tclass=file permissive=0

Bug: 34903607
Change-Id: I84721ec0e9495189a7d850461875df1839826212

Per loop(4), this device is the preferred way of allocating new
loop devices since Linux 3.1.

avc: denied { read write } for name="loop-control" dev="tmpfs" ino=15221 scontext=u:r:vold:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=0

Bug: 34903607
Change-Id: I1f5f62cf0a1c24c6f6453100004812af4b8e1503

We simplified the way we track whether or not a dex file is used by
other apps. DexManager in the framework keeps track of the data and we
no longer need file markers on disk.

Test: device boots, foreign dex markers are not created anymore

Bug: 32871170
Change-Id: I464ed6b09439cf0342020ee07596f9aa8ae53b62

This switches Keymaster HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Keymaster HAL.

Domains which are clients of Keymaster HAL, such as keystore and vold
domains, are granted rules targeting hal_keymaster only when the
Keymaster HAL runs in passthrough mode (i.e., inside the client's
process). When the HAL runs in binderized mode (i.e., in another
process/domain, with clients talking to the HAL over HwBinder IPC),
rules targeting hal_keymaster are not granted to client domains.

Domains which offer a binderized implementation of Keymaster HAL, such
as hal_keymaster_default domain, are always granted rules targeting
hal_keymaster.

Test: Password-protected sailfish boots up and lock screen unlocks --
      this exercises vold -> Keymaster HAL interaction
Test: All Android Keystore CTS tests pass -- this exercises keystore ->
      Keymaster HAL interaction:
      make cts cts-tradefed
      cts-tradefed run singleCommand cts --skip-device-info \
      --skip-preconditions --skip-connectivity-check --abi arm64-v8a \
      --module CtsKeystoreTestCases
Bug: 34170079

Change-Id: I2254d0fdee72145721654d6c9e6e8d3331920ec7

Grant observed uses of permissions being audited in domain_deprecated.

fsck
avc: granted { getattr } for path="/" dev="dm-0" ino=2 scontext=u:r:fsck:s0 tcontext=u:object_r:rootfs:s0 tclass=dir

keystore
avc: granted { read open } for path="/vendor/lib64/hw" dev="dm-1" ino=168 scontext=u:r:keystore:s0 tcontext=u:object_r:system_file:s0 tclass=dir

sdcardd
avc: granted { read open } for path="/proc/filesystems" dev="proc" ino=4026532412 scontext=u:r:sdcardd:s0 tcontext=u:object_r:proc:s0 tclass=file

update_engine
avc: granted { getattr } for path="/proc/misc" dev="proc" ino=4026532139 scontext=u:r:update_engine:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read open } for path="/proc/misc" dev="proc" ino=4026532139 scontext=u:r:update_engine:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read } for name="hw" dev="dm-1" ino=168 scontext=u:r:update_engine:s0 tcontext=u:object_r:system_file:s0 tclass=dir

vold
avc: granted { read open } for path="/vendor/lib64/hw" dev="dm-1" ino=168 scontext=u:r:vold:s0 tcontext=u:object_r:system_file:s0 tclass=dir

Test: Marlin builds and boots, avc granted messages no longer observed.
Bug: 35197529
Change-Id: Iae34ae3b9e22ba7550cf7d45dc011ab043e63424

This adds the premissions required for
android.hardware.keymaster@2.0-service to access the keymaster TA
as well as for keystore and vold to lookup and use
android.hardware.keymaster@2.0-service.

IT DOES NOT remove the privileges from keystore and vold to access
the keymaster TA directly.

Test: Run keystore CTS tests
Bug: 32020919

(cherry picked from commit 5090d6f3)

Change-Id: Ib02682da26e2dbcabd81bc23169f9bd0e832eb19

This neverallow addition addresses the renaming of files in exploits in
order to bypass denied permissions. An example of a similar use case of
using mv to bypass permission denials appeared in a recent project zero
ChromeOS exploit as one of the steps in the exploit chain.
https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html

Additionally, vold and init both had permission sets that allowed them
to rename, but neither of them seem to need it. Therefore the rename
permission has also been removed from these two .te files.

Test: The device boots successfully
Change-Id: I07bbb58f058bf050f269b083e836c2c9a5bbad80

This adds the premissions required for
android.hardware.keymaster@2.0-service to access the keymaster TA
as well as for keystore and vold to lookup and use
android.hardware.keymaster@2.0-service.

IT DOES NOT remove the privileges from keystore and vold to access
the keymaster TA directly.

Test: Run keystore CTS tests
Bug: 32020919
Change-Id: I9467ee29232cc54b48a6dae8ae240656999f73bf

There is no reason for vold to have this permission, and a proper
auditallow rule has been used and monitored to ensure that nothing on
android uses this permission.

Bug: 26901147

Test: Phone boots
Change-Id: Id36ed2722348f433fe3d046a3429066338230fec