The current implementation uses a whitelist of package names. Use a
system|signature permission instead of rolling our own security and
add that permission to the existing set of whitelisted packages
(SystemUI and VpnDialogs).
In addition to being less of a security risk (using well-known methods
like Context.enforceCallingPermission rather than manually querying
PackageManager and checking UIDs for package names), this enables
other system-privileged apps to control VPN as needed per the below
bug.
Bug: 18327583
Change-Id: I38617965c40d62cf1ac28e3cb382c0877fb1275d
Was originally removed in ag/522961, but restoring to keep legacy VPN
behavior the same from within VpnSettings. This dialog is only
accesible from VpnSettings and so should only ever be shown for legacy
VPNs.
Bug: 17164793
Change-Id: I06c4e136e1023b8f84edfd15a15264d2e41d325b
-The ability to launch VPNs is now sticky; once approved by the user,
further approvals are not needed UNLESS the connection is revoked in
Quick Settings.
-The old persistent notification has been removed in favor of the new
Quick Settings UI.
-The name of the VPN app is now pulled from the label of the VPN
service rather than the app itself, if one is set.
Bug: 12878887
Bug: 16578022
Change-Id: I102a14c05db26ee3aef030cda971e5165f078a91
If the user has supplied a backup password in Settings, that password
is validated during the full backup process and is used as an encryption
key for encoding the backed-up data itself. This is the fundamental
mechanism whereby users can secure their data even against malicious
parties getting physical unlocked access to their device.
Technically the user-supplied password is not used as the encryption
key for the backed-up data itself. What is actually done is that a
random key is generated to use as the raw encryption key. THAT key,
in turn, is encrypted with the user-supplied password (after random
salting and key expansion with PBKDF2). The encrypted master key
and a checksum are stored in the backup header. At restore time,
the user supplies their password, which allows the system to decrypt
the master key, which in turn allows the decryption of the backup
data itself.
The checksum is part of the archive in order to permit validation
of the user-supplied password. The checksum is the result of running
the user-supplied password through PBKDF2 with a randomly selected
salt. At restore time, the proposed password is run through PBKDF2
with the salt described by the archive header. If the result does
not match the archive's stated checksum, then the user has supplied
the wrong decryption password.
Also, suppress backup consideration for a few packages whose
data is either nonexistent or inapplicable across devices or
factory reset operations.
Bug 4901637
Change-Id: Id0cc9d0fdfc046602b129f273d48e23b7a14df36
- Use PendingIntent to start activities.
- Handle configs without package names.
- Switch to system UID.
Change-Id: Ia78112a97e3628b603d9e059705e32694ebe142b
