Even after having changed the SELinux policy to remove system_server's
permission to create directories like /data/system_ce/10, there's still
a very small loophole where system_server can create a subdirectory
after vold creates the directory but before vold assigns an encryption
policy to it. This isn't known to have actually happened (b/285239971
was a candidate, but it seems to have actually been caused by SELinux
being in permissive mode), but it's theoretically possible.
Close this loophole by making vold create encrypted directories under
temporary names and move them into place once they are fully prepared.
Bug: 156305599
Bug: 285239971
Test: Cuttlefish boots, and can be rebooted.
Change-Id: I53407c938bab02ab4b7e5bab8402f36eb47fb203
retrieveKey can fail in load_all_de_keys if a user
is partially removed, i.e. cases where
fscrypt_destroy_user_key() got interrupted. So just
ignore the failure, else could reboot into recovery.
Test: pm create-user foo
pm remove-user 10
adb reboot && check device not enter recovery
Signed-off-by: liulvping <liulvping@xiaomi.com>
Change-Id: Iba9d53a0833524d00e65d0427ab03002c5d8d509
Now that emulated FBE is no longer supported, there is no longer any
distinction between native FBE and emulated FBE. There is just FBE.
Referring to FBE as "fscrypt" is also poor practice, as fscrypt (the
Linux kernel support for filesystem-level encryption) is just one part
of FBE, the Android feature.
Therefore, rename fscrypt_is_native() to IsFbeEnabled().
Bug: 232458753
Change-Id: Idf4cb25d37bc3e81836fcc5a1d96f79ccfa443b7
Emulated FBE was a developer-mode feature intended to allow developers
to add Direct Boot support to apps before native FBE devices became
widely available. Since all devices running the latest version of
Android now use native FBE (except for a couple edge cases not relevant
here, like in-development devices on which encryption hasn't been
enabled yet), and emulated FBE doesn't work on native FBE devices
anyway, there's no longer any need to carry the code for emulated FBE.
Bug: 232458753
Change-Id: Ia6824699b578aca3af340fe578e26d5a5dc82b16
Having prepare_dir() and EnsurePolicy() be separate operations is
error-prone; it lengthens the window of time that files could
accidentally be created in new directories before they are encrypted,
and it makes it easier to accidentally never encrypt a directory.
To partially address this, add a function prepare_dir_with_policy() that
combines the two steps, and use it everywhere possible. This function
is now the only place in vold that calls EnsurePolicy().
As a follow-up change, we could go a bit further and make this helper
function create the directory under a temporary name and move it into
place already-encrypted. This change just focuses on getting the helper
function in place, without changing the behavior too much.
Change-Id: I98ab345df235120db6727f7dbe0da6a8b6ef2579
Prepare these directories during initUser0. This greatly shortens the
gap between the creation and encryption of /data/user/0, and this makes
it possible to remove init's write access to all directories containing
per-user encrypted directories.
Bug: 156305599
Change-Id: Ibf3d25356e8f0bca70da078c5d2428ae8615240e
Make vold explicitly set the appropriate fscreate SELinux context when
creating per-user subdirectories such as /data/user/$userId. This is
needed for these subdirectories to get the correct SELinux labels after
the sepolicy change https://r.android.com/2078213 changes their parent
directories to have different labels.
Note: the helper function being changed is also used for some other
directories, such as subdirectories of /data/misc/vold. But this is
fine since they still get the same labels as before.
Test: see https://r.android.com/2078213
Bug: 156305599
Change-Id: Id61c2d985144007059c563cec91b1355176e915c
Before doing anything else in fscrypt_prepare_user_storage(), error out
if adoptable storage is being prepared before internal storage. Without
this explicit check, making this mistake results in a sequence of weird
errors that is hard to trace back to the actual problem.
Bug: 231387956
Change-Id: Ib26cc1bd46ffa2578f6f0156dfacc5496dae3178
Make vold log warnings and errors to the kernel log until both
init_user0 has run and /data is mounted. Previously it only logged
errors, and not warnings, to the kernel log until /data is mounted.
This is helpful to diagnose failures of init_user0, since adb still
isn't started by that point.
Also, error messages can be misleading without seeing related warning
messages, e.g. the following which is expected on many devices:
E vold : keystore2 Keystore generateKey returned service specific error: -67
W vold : Failed to generate rollback-resistant key. This is
expected if keystore doesn't support rollback
resistance. Falling back to non-rollback-resistant key.
Therefore, increase the log level to WARNING and above.
Test: Intentionally broke fscrypt_init_user0(), then verified that the
error and warning messages appear in the kernel log on Cuttlefish.
Bug: 205314634
Bug: 222540970
Change-Id: Ia751f7c88cbf28caf81e891a518953cc0cee911e
We want to store sdk data on the same volume as app data. Since sdk data
is stored in misc_ce and misc_de directory, we need to ensure they exist
on adopted storage mounted at /mnt/expand/<volume-uuid>.
This CL creates `/mnt/expand/<volume-uuid>/misc_{ce,de}` directories
when disk is mouted and then when user storage is prepared, the sdk root
directory is created.
By having these directories, we can now move the sdk data to other
volume when app data is moved.
Bug: b/222034645
Test: atest SdkSandboxStorageHostTest (see ag/17120883)
Ignore-AOSP-First: End to end test added which exists in internal branch
only. Will cherry-pick this CL to aosp standalone once it is safely
merged to internal branch.
Change-Id: I0e73d9ce105abec4b77c378cde58aa7365258f01
Merged-In: I0e73d9ce105abec4b77c378cde58aa7365258f01
(cherry picked from commit b459591fd1)
This has to be allowed as a workaround until there is a way for
userspace to check the maximum DUN size directly.
Bug: 207390665
Change-Id: Id5e51720ca963fe80e65dbae1965f777b3cd2ee4
Make fixate_user_ce_key() use RenameKeyDir() to rename key directories
so that any deferred commits for these directories are also updated
appropriately.
This fixes a potential lost Keymaster key upgrade if a key were to be
re-wrapped while a user data checkpoint is pending. This isn't a huge
issue as the key will just get upgraded again, but this should be fixed.
[ebiggers@ - cleaned up slightly from satyat@'s original change]
Bug: 190398249
Change-Id: Ic6c5b4468d07ab335368e3d373916145d096af01
When a user is removed, vold is deleting the subdirectories of
/data/misc/vold/user_keys/ce/${user_id} but not that directory itself.
This is unexpected, as none of the user's directories should be left
around. Delete it too.
Bug: 188702840
Test: pm create-user foo
pm remove-user 10
stat /data/misc/vold/user_keys/ce/10 # no longer exists
Change-Id: Id4033a668fa6de1debb9ba6fdd1351c940bd35fc
This is needed so that system_server can remind itself about which users
have their storage unlocked, if system_server is restarted due to a
userspace reboot (soft restart).
Bug: 146206679
Test: see I482ed8017f7bbc8f7d4fd5a2c0f58629317ce4ed
Change-Id: I02f0494d827094bd41bcfe5f63c24e204b728595
(cherry picked from commit 1799debfd6)
HardwareAuthTokens are no longer used by vold since Android P. So remove
the auth token parameter from vold. This patch doesn't remove the token
from IVold.aidl, and the methods in VoldNativeService.cpp return an
error if a non-empty auth token is passed to them.
Bug: 181910578
Test: cuttlefish and bramble boot with patch
Change-Id: I1a9f54e10f9efdda9973906afd0a5de5a699ada5
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: Ic5d63457ec917ea407b900dbb7773d89311780c6
vold creates some directories for storing encryption keys if they don't
already exist, potentially including parent directories:
/metadata/vold/metadata_encryption
/data/misc/vold/volume_keys/$volume_uuid
/data/misc_de/$user/vold/volume_keys/$volume_uuid
/data/misc_ce/$user/vold/volume_keys/$volume_uuid
Currently fs_mkdirs() is used for this. However, fs_mkdirs() doesn't
include the fsync()s of the parent directories that are needed to ensure
that the new directories are persisted to disk right away -- which is
important for encryption keys.
Add a utility function MkdirsSync() which does what is needed, and make
the appropriate places call it.
Test: Booted and checked log for "Created directory" message.
Also ran 'atest vold_tests' to run the new unit test.
Change-Id: Ie9917b616433080139b8db3fd6877203ee6faf77
When an FBE or metadata encryption key is created, it's important that
it be persisted to disk right away; otherwise the device may fail to
boot after an unclean shutdown. storeKey() has the needed fsync()s.
However, storeKeyAtomically() doesn't, as it doesn't fsync() the parent
directory of key_path after it renames tmp_path to it.
Two callers do fsync() the parent directory themselves, but others
don't. E.g., the metadata encryption key doesn't get properly synced.
Therefore, add the needed fsync() to storeKeyAtomically() so that it
gets done for everyone.
Also remove the now-unneeded fsync()s from the two callers that did it
themselves.
Change-Id: I342ebd94f0a3d2bf3a7a443c35b6bda0f12e1ab2
This reverts commit a71323ec0e.
Reason for revert: b/177926359 - note that this is a Google testing infrastructure issue, and no issue with this patch. Partners can keep using this patch. It will be resubmitted in a few weeks.
Change-Id: Ia13279ac1aafa2e4425c4527aeadd5d0fadbc2e4
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: Ib718b8362df84754ee3cac33865bca3c12df2e3a
This directory is used as a root for external storage on adopted storage
devices. It needs to be writable by processes holding the AID_MEDIA_RW
GID permission; in particular, it should be writable by the FUSE daemon.
On devices with sdcardfs, this was ensured automatically, because
sdcardfs presented a view of this directory that was writable, that we
could use for the FUSE daemon. But on devices without sdcardfs, the FUSE
daemon sees the raw filesystem and its permissions. This also means that
files created by the FUSE daemon will have their uid/gid set to the uid
of the FUSE daemon; to ensure these files stay writable to other system
applications that have AID_MEDIA_RW, use a default ACL to make sure the
gid stays AID_MEDIA_RW.
In particular, this fixes an issue with app cloning, where we want the
FUSE daemon of user 0 to be able to access the files of the app clone
user, and vice versa.
Bug: 154057120
Test: inspect uid/gid of /data/media/0 and contents
Change-Id: I6dfae41f9cb6a8283978b2667b02708a000f07c0
This is already on for all Pixel devices with no problems observed.
If this causes issues with a specific device (e.g. vendor apps being
unable to access their data) it can be temporarily disabled by adding
PRODUCT_PROPERTY_OVERRIDES += ro.vold.level_from_user=0
to the device.mk file. Please file a bug if that happens.
Bug: 141677108
Test: presubmits
Change-Id: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
Merged-In: Ic9da534f1a5f4c9e3bd62ea5c09a3b11ebcb33e7
(cherry picked from commit 763393644a)
Remove the error-prone 'keepOld' parameter, and instead make begin()
(renamed to BeginKeymasterOp()) do all the key upgrade handling.
Don't handle /data and /metadata differently anymore. Previously, when
a checkpoint is active, key blob files were replaced on /data
immediately; only the actual Keymaster key deletion was delayed until
checkpoint commit. But it's easier to just delay the key blob file
replacement too, as we have to implement that for /metadata anyway.
Also be more vigilant about deleting any leftover upgraded keys.
Test: Tested on bramble using an OTA rvc-d1-release => master. In OTA
success case, verified via logcat that the keys were upgraded and
then were committed after the boot succeeded. In OTA failure
case, verified that the device still boots -- i.e., the old keys
weren't lost. Verified that in either case, no
keymaster_key_blob_upgraded files were left over. Finally, also
tried 'pm create-user' and 'pm remove-user' and verified via
logcat that the Keymaster keys still get deleted.
Change-Id: Ic9c3e63e0bcae0c608fc79050ca4a1676b3852ee
Commit 77df7f207d / http://aosp/1217657 ("Refactor to use
EncryptionPolicy everywhere we used to use raw_ref") unintentionally
made fscrypt_initialize_systemwide_keys() start specifying keepOld=true
(via default parameter value) when retrieving the system DE key, and
likewise for read_or_create_volkey() and volume keys.
As a result, if the associated Keymaster key needs to be upgraded, the
upgraded key blob gets written to "keymaster_key_blob_upgraded", but it
doesn't replace the original "keymaster_key_blob", nor is the original
key deleted from Keymaster. This happens at every boot, eventually
resulting in the RPMB partition in Keymaster becoming full.
Only the metadata encryption key ever needs keepOld=true, since it's the
only key that isn't stored in /data, and the purpose of keepOld=true is
to allow a key that isn't stored in /data to be committed or rolled back
when a userdata checkpoint is committed or rolled back.
So, fix this bug by removing the default value of keepOld, and
specifying false everywhere except the metadata encryption key.
Note that when an affected device gets this fix, it will finally upgrade
its system DE key correctly. However, this fix doesn't free up space in
Keymaster that was consumed by this bug.
Test: On bramble:
- Flashed rvc-d1-dev build, with wiping userdata
- Flashed a newer build, without wiping userdata
- Log expectedly shows key upgrades:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /metadata/vold/metadata_encryption/key
D vold : Upgrading key: /data/unencrypted/key
D vold : Upgrading key: /data/misc/vold/user_keys/de/0
D vold : Upgrading key: /data/misc/vold/user_keys/ce/0/current
- Rebooted
- Log unexpectedly shows the system DE key being upgraded again:
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" unexpectedly still exists:
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
/data/unencrypted/key/keymaster_key_blob_upgraded
- Applied this fix and flashed, without wiping userdata
- Log shows system DE key being upgraded (expected because due to the
bug, the upgraded key didn't replace the original one before)
$ adb logcat | grep 'Upgrading key'
D vold : Upgrading key: /data/unencrypted/key
- "keymaster_key_blob_upgraded" expectedly no longer exists
$ adb shell find /data /metadata -name keymaster_key_blob_upgraded
- Rebooted
- Log expectedly doesn't show any more key upgrades
$ adb logcat | grep 'Upgrading key'
Bug: 171944521
Bug: 172019387
Change-Id: I42d3f5fbe32cb2ec229f4b614cfb271412a3ed29
We want various per-user directories to have their SELinux MLS level
set to restrict access from other users, as an improvement to user
isolation.
We extend vold_prepare_subdirs to implement this if a flag is
set. vold itself then sets the flag based on a new property,
ro.vold.level_from_user. This is to allow testing of further
incremental work to ensure system apps correctly handle the new
restriction on different devices rather than causing immediate
breakage. Eventually this will go away and the restriction will apply
everywhere.
Bug: 141677108
Test: Manual, with and without propery set.
Change-Id: I8e2207bd94b487bdcc09fd4d80b031027dfea1e3
The name "pre_gki_level" is causing some confusion because not all
devices launching with Android R are subject to the GKI requirement.
(See b/161563110#comment11.) E.g., devices that use a 4.14-based kernel
are exempt from GKI. However, the encryption requirements still apply.
Just use __ANDROID_API_Q__ directly instead.
No change in behavior.
Change-Id: Id02ae1140845ac1ae7cf78be4e57fe34da028abf
The emmc_optimized encryption flag is specifically designed for the
limitations of inline encryption hardware that follows the eMMC
standard. It isn't appropriate to use on other types of storage.
So, make vold enforce that it's not used on other types of storage.
Bug: 160639344
Test:
- Enabled emmc_optimized on Cuttlefish and verified it no longer boots
- Using a modified version of this change, verified that
IsEmmcStorage() works as expected on various devices including
Cuttlefish, Cuttlefish booted in GSI image mode, a device with eMMC
storage, and a device with UFS storage.
- Verified that VtsKernelEncryptionTest still passes
Change-Id: Ie27b80658db53b1a4207b3cbb4e309d05130812e
During userspace reboot /data might be unmounted & remounted, meaning
that CE keys stored in fs-level keyring will be lost. In order to be
able to restore them, when installing new key to fs-level keyring, it's
also added to session-level keyring with type "fscrypt-provisioning".
Then when init_user0 is called during userspace reboot, vold will try to
load CE keys from the session-level keyring back into fs-level keyring
for all the users that were unlocked before the reboot.
If for any user vold fails to install the key, init_user0 will fail and
fallback to hard reboot will be triggered.
Test: set a pin pattern
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
Merged-In: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
(cherry picked from commit 1ee35cf002)
Previously every directory on external storage had project ID quota
inheritance enabled; this means that if any new file/directory is
created under such a directory, it will inherit the project ID from the
parent. We use a default project ID of 1000 for generic directories, and
application-specific project IDs for app-specific directories.
MediaProvider is responsible for updating the quota type in the generic
directories, as it scans all files there. However, there is a problem
with this approach: if you move a file to a directory with project ID
inheritance set, and the project ID of that file differs from the
project ID of the dir, that results in an EXDEV error, and requires a
copy instead. For example, if /sdcard/DCIM/test.jpg has a project ID of
1003 (for images), and you try to move it to /sdcard/Pictures/test.jpg,
that would require a copy, because the project ID of /sdcard/Pictures is
1000.
While this is not a very common scenario, it's still better to avoid it.
Luckily we can - since MediaProvider anyway scans all files, it will set
the project ID on individual files correctly - there's no need to
inherit them.
We then only need to inherit quota in application-specific directories,
since in those directories the app can create files itself, and those
need to be tagged correctly.
This change enables that, by removing quota inheritance setting from the
top-level directory, and instead doing it for app-specific directories
instead.
Bug: 151078664
Test: atest StorageHostTest
atest com.android.tests.fused.host.FuseDaemonHostTest#testRenameAndReplaceFile
Change-Id: I38a057ec61cb627e39a3ff7ac58c7218dc251bdc
During userspace reboot /data might be unmounted & remounted, meaning
that CE keys stored in fs-level keyring will be lost. In order to be
able to restore them, when installing new key to fs-level keyring, it's
also added to session-level keyring with type "fscrypt-provisioning".
Then when init_user0 is called during userspace reboot, vold will try to
load CE keys from the session-level keyring back into fs-level keyring
for all the users that were unlocked before the reboot.
If for any user vold fails to install the key, init_user0 will fail and
fallback to hard reboot will be triggered.
Test: set a pin pattern
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I37603dc136c7ededc7b0381e4d730cb0ffd912b4
During userspace reboot /data might be unmounted, which means that if
device supports filesystem keyring, DE keys will be lost and are needed
to be re-installed.
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I153caa1d7c373b3c906a34f1184c681e52854a9d
Merged-In: I153caa1d7c373b3c906a34f1184c681e52854a9d
(cherry picked from commit 1eaea5a6a2)
During userspace reboot /data might be unmounted, which means that if
device supports filesystem keyring, DE keys will be lost and are needed
to be re-installed.
Test: adb shell setprop sys.init.userdata_remount.force_umount 1
Test: adb shell svc power reboot userspace
Test: atest CtsUserspaceRebootHostSideTestCases
Bug: 143970043
Change-Id: I153caa1d7c373b3c906a34f1184c681e52854a9d
