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
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
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
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
