shipping API version:
For devices shipped before Android P nothing changes, data
is stored under /data/system/users/<user-id>/fpdata/...
Devices shipped from now on will instead store
fingerprint data under /data/vendor_de/<user-id>/fpdata.
Support for /data/vendor_de and /data/vendor_ce has been added to vold.
Bug: 36997597
Change-Id: I615e90d1c9ab08e768a8713968fa043598a0a526
Test: manually
Protect all per-volume-per-user keys with a per-volume key, which is
forgotten when the volume is forgotten. This means that the user's key
is securely lost even when their storage is encrypted at forgetting
time.
Bug: 25861755
Test: create a volume, forget it, check logs and filesystem.
Change-Id: I8df77bc91bbfa2258e082ddd54d6160dbf39b378
When we set up encryption on real volumes - not just /data - we should
give them their own keys, so that these keys can be deleted when the
volume is forgotten. Also, we must choose the encryption modes
differently, since ICE encryption which works on /data may not work on
such volumes.
Bug: 25861755
Test: boot device, add SD card, check modes.
Change-Id: I354cd651757c3566dba046ae99d324833ad9b0e5
Minimize overhead in boot by replacing shell script invoked multiple
times with a C++ program invoked once.
Bug: 67901036
Test: create user, run adb shell ls -laZ /data/misc_ce/10; delete user
and check logs.
Change-Id: I886cfd6505cca1f5b5902f2071e13f48e612214d
Use vold_prepare_subdirs since only it has the privilege needed.
Bug: 25861755
Test: Boot device, create user, create files, remove user, observe logs
Change-Id: I90fb2517ccd177c9b009001e7a2b00f537152f8c
Now that we've moved to Binder, we only have a few lingering atoi()
usages that are cleaned up in this CL.
Rewrite match_multi_entry() entirely, with tests to verify both old
and new implementations.
Test: adb shell /data/nativetest/vold_tests/vold_tests
Bug: 36655947
Change-Id: Ib79dc1ddc2366db4d5b4e1a1e2ed9456a06a983e
std::vector with custom zeroing allocator is used instead of
std::string for data that can contain encryption keys.
Bug: 64201177
Test: manually created a managed profile, changed it's credentials
Test: manually upgraded a phone with profile from O to MR1.
Change-Id: Ic31877049f69eba9f8ea64fd99acaaca5a01d3dd
Older make_ext4fs doesn't support enabling quotas, so switch everyone
over to using mke2fs for adoptable storage.
Remove UUID check so that we start setting ext4-crypto policies on
adoptable storage devices; a future change will handle the actual
key management.
Bug: 30230655, 36757864
Test: cts-tradefed run commandAndExit cts-dev --abi armeabi-v7a -m CtsAppSecurityHostTestCases -t android.appsecurity.cts.AdoptableHostTest
Change-Id: I021f85b1be8431044c239521c37be96534682746
This is used by LockSettingsService to delete sensitive credential files.
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I5e11b559ad8818bd2ad2b321d67d21477aab7555
This reverts commit 6abe6831b5.
Bringing this back temporarily for the same issue on sdcardfs.
Will remove once the kernel issue is resolved.
Change-Id: Ia29ea4fddb7777012a2eea9259f9ac856773fe01
Bug: 37231161
Test: Boot device with FBE enabled. ls /storage/emulated/0/Android
Unlock device. ls /storage/emulated/0/Android
1st will not be found. Second should be found.
Unlinking keys rather than revoking them avoids bugs in certain kernel
versions without having to hack around the problem with an arbitrary 20
second delay, which is not guaranteed to be sufficient and has caused
full device hangs like in b/35988361.
Furthermore, in the context of filesystem encryption, unlinking is not
currently supposed to be any less secure than revoking. There was a
case where revoking (but not unlinking) keys will cause the filesystem
to deny access to files that were previously opened with that key.
However, this was a means of _access control_, which encryption is not
intended to be used for. Instead, file permissions and/or SELinux
should be used to enforce access control, while filesystem encryption
should be used to protect data at rest independently from access
control. This misfeature has also been removed upstream (and backported
to 4.4-stable and 4.9-stable) because it caused CVE-2017-7374.
Eventually we'd really like to make the kernel support proper revocation
of filesystem encryption keys, i.e. fully clearing all key material and
plaintext and safely waiting for any affected filesystem operations or
writeback to complete. But for now this functionality does not exist.
('sync && echo 3 > /proc/sys/vm/drop_caches' can be useful, but it's not
good enough.)
Bug: 35988361
Change-Id: Ib44effe5368cdce380ae129dc4e6c6fde6cb2719
(cherry picked from commit fd7ba5e4c6)
We simplified the way we track whether or not a dex file is used by
other apps. DexManger 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: Id0360205b019be92049f36eab4339f4736e974f4
Make the vold changes needed to support specifying aes-256-heh filenames
encryption. The previous mode, aes-256-cts, remains supported as well.
The file /data/unencrypted/mode is updated to have the syntax
contents_encryption_mode[:filenames_encryption_mode] instead of just
contents_encryption_mode. This is consistent with the new fstab syntax.
Bug: 34712722
Change-Id: Ibc236d0ec4fdeda4e4e301f45fb996317692cfa3
A work around for a kernel bug is needed to avoid the phone locking up
and turning into a hand warmer.
Test: com.android.cts.devicepolicy.ManagedProfileTest#testLockNowWithKeyEviction*
Bug: 31000719
Change-Id: Ia2121b3e3c22b10351296fa998892a91e601bb2c
Vold is considered part of our trusted computing base, and
compromising vold is already identified as a complete device
compromise. While storing keys only in the kernel would be better, the
current setup does not introduce a security bug or worsen any security
control.
Bug: 26948053
Test: Comment-only change.
Change-Id: Ib5436f4386769ec44b74dc6b50fbcc0fed99b96b
Ephemeral users don't have keys stored on disk at all, so it's neither
necessary nor possible to manipulate the disk keys here.
Bug: 30038313
Change-Id: Idc7ec1bfe1e8a6ffa6cee2f284dbe378097b08da
On FBE devices, the filenames inside credential-encrypted directories
are mangled until the key is installed. This means the initial
restorecon at boot needs to skip these directories until the keys
are installed.
This CL uses an existing facility to request that init run a
recursive restorecon over a given path, and it requests that
operation for the CE directories that would have been omitted by
the SKIPCE flag earlier during boot.
Bug: 30126557
Change-Id: I8c7abea27215075a091f615a7185a82a2f4a4a95
am: a363036b44
* commit 'a363036b44f7f140aa9a943578f56abff5880a60':
Two phases to set the password for disk encryption
Change-Id: Ia28823079d8c0bda220238339f28095b234a0ae5
Revert "Revert "Two phases to set the password for disk encryption""
This reverts commit d402389290.
In addition, fix the bug in the original commit.
Bug: 28154455
Bug: 28694324
Change-Id: I885f1d73e739416347c135d79979941c2bbdbe62
am: cfa03d4a4c
* commit 'cfa03d4a4c53acf41dca2c41a2efd00de06043bb':
e4crypt_is_native has been moved into system/extras.
Change-Id: I345475c44fb2d8812a25c9f2195c748cddc55bfe
am: d402389290
* commit 'd402389290eeef86be7eb9241e20fdd125d44eb1':
Revert "Two phases to set the password for disk encryption"
Change-Id: I53a3804fc7bff9c99840aeee36fc4b7ff8e46ac1
am: 92c5eeb467
* commit '92c5eeb46779f0fa1c9e6db6b0d632d960cbb2e4':
Two phases to set the password for disk encryption
Change-Id: I82c1cfa2874ac4709e42f5c2047c832cbcaccb91
In one phase, we make the new password work, and in the second we make
it the only one which works ("fixation"). This means that we can set
the password in Gatekeeper between these two phases, and a crash
doesn't break things. Unlocking a user automatically fixates the
presented credential.
Bug: 28154455
Change-Id: I54623c8652f0c9f72dd60388a7dc0ab2d48e81c7
Preparing and destroying users currently needs to be split across
installd, system_server, and vold, since no single party has all the
required SELinux permissions.
Bug: 27896918, 25861755
Change-Id: Ieec14ccacfc7a3a5ab00df47ace7318feb900c38
Users don't have to be unlocked to be deleted, so don't worry if we
don't have their key to evict.
Bug: 26847403
Bug: 27441228
Change-Id: Ifd93f620926630aa102a3bb4a5d2d45d34f9b75d
The formatting here is inconsistent with Android house style; use
clang-format to bring it back into line.
Change-Id: Id1fe6ff54e9b668ca88c3fc021ae0a5bdd1327eb
Google/Android C++ style requires that arguments passed in for writing
should be pointers, not references, so that it's visible in the caller
that they'll be written to.
Bug: 27566014
Change-Id: I5cd55906cc4b2f61c8b97b223786be0b3ce28862
