vold needs write permissions for /sys/block/*/uevent to perform a
coldboot.
https://android.googlesource.com/platform/system/vold/+/refs/heads/master/main.cpp#139
This denial is seen on cuttlefish:
avc: denied { write } for name=uevent dev=sysfs ino=11649
scontext=u:r:vold:s0 tcontext=u:object_r:sysfs_devices_block:s0
tclass=file permissive=1
Pixel devices resolve this denial in device policy, but since coldboot
is performed from platform code, the corresponding permission should be
in /system/sepolicy
Bug: 28053261
Test: boot cuttlefish without above denial
Change-Id: I2de08db603e2d287e8021af70ee8e69266d7736f
System suspend service is not a HAL, so avoid using HAL-specific macros
and attributes.
Use system_suspend_server attribute for ISystemSuspend.hal permissions.
Use system_suspend type directly for internal .aidl interface
permissions.
Bug: 126259100
Test: m selinux_policy
Test: blueline boots; wakelocks can still be acquired; device suspends
if left alone.
Change-Id: Ie811e7da46023705c93ff4d76d15709a56706714
This lets update_verifier call supportsCheckpoint to defer marking the
boot as successful when we may end up failing before we would commit
the checkpoint. In this case, we will mark the boot as successful just
before committing the checkpoint.
Test: Check that marking the boot as succesful was deferred in
update_verifier, and done later on.
Change-Id: I9b4f3dd607ff5301860e78f4604b600b4ee416b7
all_untrusted_apps apart from untrusted_app_{25, 27} and mediaprovider
are now expected to go to ashmemd for /dev/ashmem fds.
Give coredomain access to ashmemd, because ashmemd is the default way
for coredomain to get a /dev/ashmem fd.
Bug: 113362644
Test: device boots, ashmemd running
Test: Chrome app works
Test: "lsof /system/lib64/libashmemd_client.so" shows
libashmemd_client.so being loaded into apps.
Change-Id: I279448c3104c5d08a1fefe31730488924ce1b37a
To configure read-ahead on loop devices, eg.
/sys/devices/virtual/block/loop0/queue/read_ahead_kb
Bug: 120776455
Test: configuring read-ahead on loop devices works from apexd
Change-Id: Ib25372358e8ca62fa634daf286e4b64e635fac58
Never use popen, just execvp directly
Test: Two tests
- Ensure Marlin device boots and vold_prepare_subdirs is called
successfully
- Try adb shell sm set-virtual-disk true, see that eg sgdisk output is
logged.
Bug: 26735063
Bug: 113796163
Change-Id: Icb34140429db85098a0118a2b833772e3620e7ac
Hals have 3 attributes associated with them, the attribute itself, the
_client attribute, and the _server attribute. Only the server attribute
isn't expanded using the expandattribute keyword, and as a result, is
the only attribute which can be used in neverallow rules.
Fix neverallow rule to use hal_bootctl_server, which is not expanded,
instead of hal_bootctl.
Introduced in: https://android-review.googlesource.com/c/platform/system/sepolicy/+/777178
Test: policy compiles
Bug: 119500144
Change-Id: I8cff9cc03f4c30704175afb203c68f237fbd61ca
The auditallow added in commit
7a4af30b38 ("Start the process of locking
down proc/net", May 04 2018), has not been triggered. This is safe to
delete.
Test: Policy compiles
Test: no collected SELinux denials
Bug: 68016944
Change-Id: Ib45519b91742d09e7b93bbaf972e558848691a80
BLKDISCARD is used by vold while wiping block devices
b2455747a9/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: 0c7e133c7f/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
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
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
Start enforcing the use of ioctl restrictions on all Android block
devices. Domains which perform ioctls on block devices must be explicit
about what ioctls they issue. The only ioctls allowed by default are
BLKGETSIZE64, BLKSSZGET, FIOCLEX, and FIONCLEX.
Test: device boots and no problems.
Change-Id: I1195756b20cf2b50bede1eb04a48145a97a35867
This is needed to find the file on the raw block device, so it can be
securely deleted.
Addresses the following denials:
type=1400 audit(0.0:492): avc: denied { ioctl } for comm="secdiscard" path="/data/misc/vold/user_keys/ce/10/current/encrypted_key" dev="dm-3" ino=9984 ioctlcmd=0x660b scontext=u:r:vold:s0 tcontext=u:object_r:vold_data_file:s0 tclass=file permissive=0
type=1400 audit(0.0:517): avc: denied { ioctl } for comm="secdiscard" path="/data/misc/vold/user_keys/ce/11/current/secdiscardable" dev="dm-3" ino=9581 ioctlcmd=0x660b scontext=u:r:vold:s0 tcontext=u:object_r:vold_data_file:s0 tclass=file permissive=0
type=1400 audit(0.0:694): avc: denied { ioctl } for comm="secdiscard" path="/data/misc/vold/user_keys/ce/0/current/keymaster_key_blob" dev="dm-3" ino=9903 ioctlcmd=0x660b scontext=u:r:vold:s0 tcontext=u:object_r:vold_data_file:s0 tclass=file permissive=0
Test: policy compiles and device boots
Change-Id: I1adf21b7fa92b1f92ce76532f4d9337a4d58a2e5
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
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
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
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 597be44e96)
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 087318957f)
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
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 640e595a68. The
corresponding code in libcutils was removed, so this is now unneeded.
Bug: 71632076
Test: aosp_sailfish still works
Change-Id: I615bab83e9a83bc14439b8ab90c00d3156b0a7c4
Commit 7688161 "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 ed876a5e96.
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 7688161 "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
