Since MANAGE_MISC_DIRS is hardcoded to 0, and it always has been, there
is no need to have it in the code.
Test: build
Change-Id: I30a73e67999841271e07dbc3eeb1b8568529a7c3
createUserStorageKeys(), unlockCeStorage(), and prepareUserStorage()
have a user serial number parameter, but they don't actually do anything
with it except log it. Remove this unnecessary parameter.
Bug: 316035110
Test: presubmit
Flag: N/A, mechanical refactoring
Change-Id: I73ebae1afb2bdb7ca856b40b34ce806fdda718fe
The android-4.14-stable and later kernels support the
FS_IOC_ADD_ENCRYPTION_KEY and FS_IOC_REMOVE_ENCRYPTION_KEY ioctls. This
has superseded the old way of adding fscrypt keys to the kernel, which
was to use the add_key() syscall to add keys to the "session" keyring.
On kernels that support the ioctls, Android doesn't use the obsolete
way. Since upgrading even just to Android 14 requires at minimum a
android-4.14-stable kernel (according to
https://source.android.com/docs/core/architecture/kernel/android-common#compatibility-matrix),
there is no need to support the obsolete way anymore.
Therefore, this commit removes the code that added and removed keys
to/from the session keyring. Now the ioctls are used unconditionally.
Flag: N/A for the following reasons:
- Removing obsolete code, which is fairly safe
- Very early code, so runtime flag cannot be used
- This topic also removes code from init, which cannot use aconfig
libraries because they do not support recovery_available
Bug: 311736104
Test: Build and boot Cuttlefish
Change-Id: I0d9abbda77b1ac838ea6f014dbe22ab032c0e5ae
Rename methods that refer to "user key" to be more precise about what
they mean. For more details, see the corresponding frameworks/base
changes (I202ebbfd2b4f79fedb3ed120a8ad81500c126894 and
I5894beb97823dced5954e405d779fada49c79e8d).
No change in behavior except for some changed log messages.
Flag: exempt, mechanical refactoring only
Test: presubmit
Change-Id: I9edcb557172395f4f6cf8e837efcc06fcfefb37d
Userspace reboot turned out to be a dead end and is no longer supported.
Therefore, remove the code from vold that handled keeping CE storage
unlocked past the userdata filesystem being unmounted and mounted.
This is a revert of commit 1c6731c649 (https://r.android.com/1254615)
with various conflicts resolved.
Bug: 292469129
Change-Id: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
Merged-In: If530edaf7c1566dd3bd8b1322f935f38a2e66beb
(cherry picked from commit 2b97a88ba4)
Adoptable storage CE and DE keys were not being explicitly evicted,
resulting in the benefits of key eviction not being fully realized on
devices that use adoptable storage. Fix this by evicting the adoptable
storage keys when the corresponding internal storage keys are evicted:
- In lockUserKey, evict the CE keys for adoptable storage volumes, not
just the CE key for internal storage as was done before.
- In destroyUserKey, evict the user's CE and DE keys for adoptable
storage, not just the internal storage keys as was done before.
To make this possible, starting keeping track of the EncryptionPolicy of
each currently installed adoptable storage key.
(This CL is reworked from https://r.android.com/2660878,
original author Arnab Sen <arnabse@amazon.com>)
Test: On Cuttlefish with config_multiuserMaxRunningUsers changed to 1:
sm set-virtual-disk true
sm partition disk:7,416 private
pm create-user 10
am start-user 10
am stop-user 10
# Verified that this fails with "Required key not available".
touch /mnt/expand/f1ad173b-d6d9-4948-8eb7-ccdd7b053b22/misc_ce/10/foo.txt
am start-user 10
pm remove-user 10
# Checked for all the expected "Evicted fscrypt key" messages.
# 2 from when user was stopped, and 4 from when user was removed.
adb logcat | grep Evicted
Change-Id: I7f11a135d8550618cd96013f834cebd54be5ef84
Merged-In: I7f11a135d8550618cd96013f834cebd54be5ef84
(cherry picked from commit 68fd3689a1)
Erasing a key from s_new_ce_keys is equivalent to destroying it, so it
shouldn't be done when the key is merely being evicted.
This didn't matter in practice since eviction requests don't come in
before the key gets persisted, but fix this to avoid confusion.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: I28412f243925b5a7242449b617fe9de9c90912b6
Merged-In: I28412f243925b5a7242449b617fe9de9c90912b6
(cherry picked from commit 3529302ede)
Everything in FsCrypt.cpp seems to run under VolumeManager::mCryptLock,
except for fscrypt_destroy_volume_keys() which uses mLock instead.
This was sort of okay because fscrypt_destroy_volume_keys() didn't
operate on any in-memory data structures. However, that is going to be
changed. Therefore, rework VoldNativeService::forgetPartition() to call
fscrypt_destroy_volume_keys() under mCryptLock.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
Merged-In: Ia27a61faf2fdd546cdbddb2a3985c7c6696f6aa6
(cherry picked from commit ce86e24d23)
No change in behavior, except for removing a redundant check of
's_ce_policies.count(user_id)' and removing an extra ERROR message.
Test: see I7f11a135d8550618cd96013f834cebd54be5ef84
Change-Id: If221e23991e8e04138ae7dbdafe8160b00893655
Merged-In: If221e23991e8e04138ae7dbdafe8160b00893655
(cherry picked from commit 92428b247f)
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
On the first boot after an upgrade, ensure that any Keystore key
deletions triggered by fscrypt_set_user_key_protection() are deferred
until the userdata filesystem checkpoint is committed, so that the
system doesn't end up in a bad state if the checkpoint is rolled back.
Test: see I77d30f9be57de7b7c4818680732331549ecb73c8
Bug: 232452368
Ignore-AOSP-First: depends on other changes in internal master
Change-Id: I59b758bc13b7a2ae270f1a6c409affe2eb61119c
Cache the EncryptionOptions for /data in a static variable so that it
doesn't have to be repeatedly regenerated from the fstab.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Ignore-AOSP-First: depends on other changes in internal master
Change-Id: I24b27190ed807f142b793d3cf250ec271d092f34
Directory syncs can be expensive, so only sync the directory in
fixate_user_ce_key() if something was actually done, i.e. if at least
one key directory was deleted or renamed. Previously, the unconditional
sync in this function was being executed whenever the CE key was
retrieved or stored. Note that all the syncs needed when storing the
key already happen in storeKeyAtomically(); this one was unrelated.
Bug: 232452368
Bug: 251131631
Bug: 251147505
Ignore-AOSP-First: depends on other changes in internal master
Change-Id: Ib0f2b9e27cdd11e359a1618cddc1f5480bd2fd37
Try to be more robust in the case where the device is rebooted during
the first boot, in between the generation and the storage of the CE key
for a user other than user 0. This is relevant when users are created
during early boot, which Automotive devices do.
Bug: 232452368
Bug: 251213447
Ignore-AOSP-First: depends on other changes in internal master
Change-Id: Ic8f19a36c1385a71a168a330e87675433925a60f
Try to be more robust in the case where the device is rebooted during
the first boot, in between the generation and the storage of user 0's CE
key. We can automatically recover from this scenario by generating a
new CE key and replacing /data/data.
This might resolve b/251213447.
Bug: 232452368
Bug: 251213447
Ignore-AOSP-First: depends on other changes in internal master
Change-Id: If0675de9167f7f855c0c0c6afe55fd1da39f5ce1
When generating a CE key, don't persist it immediately with
kEmptyAuthentication. Instead, cache it in memory and persist it later
when the secret to protect it with is given. This is needed to make it
so that the CE key is always encrypted by the user's synthetic password
while it is stored on-disk. See the corresponding system_server changes
for more information about this design change and its motivation.
As part of this, simplify vold's Binder interface by replacing the three
methods addUserKeyAuth(), clearUserKeyAuth(), and
fixateNewestUserKeyAuth() with a single method setUserKeyProtection().
setUserKeyProtection() handles persisting the key for a new user or
re-encrypting the default-encrypted key for an existing unsecured user.
Bug: 232452368
Ignore-AOSP-First: This depends on frameworks/base changes that can only
be submitted to internal master, due to conflicts.
Test: see Ia753ea21bbaca8ef7a90c03fe73b66c896b1536e
Change-Id: Id36ba8ee343ccb6de7ec892c3f600abd636f6ce5
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
