stop exempting VPN app from leak blocking#315
Open
liamsmith827 wants to merge 460 commits intoGrapheneOS:16-qpr2from
Open
stop exempting VPN app from leak blocking#315liamsmith827 wants to merge 460 commits intoGrapheneOS:16-qpr2from
liamsmith827 wants to merge 460 commits intoGrapheneOS:16-qpr2from
Conversation
This allows to skip restarting them after post-OTA asynchronous optimization, which some VPN service hosts don't handle properly.
Some of per-app features (e.g. SELinux restrictions) require app process restart to be applied.
Value of the previous global setting is used as a default value of the new per-app setting. For system apps, native debugging is blocked unconditionally.
"App info" screen for controlling ptrace access is linked from this notification.
All non-app tombstones were considered to have the same processName ("UNKNOWN"), which meant that
frequent tombstones from one system process rate-limited tombstones from all system processes.
Instances of FileList and EntryFile are stored in java.util.TreeSet. TreeSet requires that compareTo() is consistent with equals().
System error file contents are added to the DropBox when file's timestamp changes. Last known file timestamps are kept in a separate file. This race condition caused some updates to last known timestamps getting lost, which led to their corresponding system error files being treated as new system errors after device reboot.
Show notifications about the following events:
- kernel crash (from last_kmsg) (optional)
- file system check error
- system_server crash (Java or native)
- system app native crash (optional, except for memory tagging crashes)
- non-app process native crash (optional, except for memory tagging crashes)
- some of hardened_malloc app crashes (those that are caused by fatal_error() call in hardened_malloc
after it detects an app error)
These events are recorded in the system journal ("DropBox") already, this commit surfaces them to
the user.
Currently covers restriction of dynamic code loading via memory/storage and blocking of ptrace access. Testing is performed on three kinds of HardeningTestApp: targetSdk 27, current targetSdk and preinstalled current targetSdk app (the latter is included on debuggable builds). Preinstalled app is tested separately to make sure that restrictions can't be weakened for it, regardless of GosPackageState values. To run the test, execute `atest HardeningTest`.
ART has special support for System.gc() and Android already uses this to purge memory after unlocking. It makes sense to purge as much as we can when locking too.
Adoptable storage is not available on any of the currently supported devices. Handling of adoptable storage would complicate the duress password implementation.
The device might become non-unlockable if it's protected with a password and a broken third-party keyboard is used. The system keyboard is unconditionally used in safe mode. There's already an option to reboot to safe mode by pressing and holding the "Restart" button, but its discoverability is low.
The second argument of (String, int) overload is a flags integer. userId can by passed by using the (String, int, UserHandle) overload, but that's not needed in this case since the default userId is the app context userId.
This reverts commit 95970b9.
This reverts commit 58ce80e.
This workaround doesn't work.
Network location provider is disabled by default on GrapheneOS and is not as accurate as the GmsCore network location implementation. Upstream 16 QPR1 change: e149021
Some apps perform a weak security check by looking at the main thread stack trace.
This reverts commit 31db9b9.
The 2FA implementation was catching its own minor bug and as a result the second factor lockscreen was unable to be dismissed when a fingerprint was authenticated after KeyguardUpdateMonitor started going to sleep. Now, when 2FA is enabled, fingerprint authentication after the device has started going to sleep will be ignored. It is rare that a fingerprint gets authenticated during this tiny window, so this will not be noticeable or reduce user experience.
Android provides VPN apps the capability to protect sockets that should bypass the tunnel and leak blocking protection. It is then expected that any socket that is not protected should not get a bypass. This is clearly documented and easy for VPN app developers to implement. However, Android decided that some VPN apps might forget to protect their sockets and added an exemption that allows the VPN app to bypass leak blocking protection, even for unprotected sockets. As a result of this exemption, the VPN app has no way to force traffic through the tunnel, so anything it wishes to send through the tunnel is subject to being leaked. This change removes the exemption. If a VPN app breaks due to this change it is, by definition, a broken app that was being saved by a workaround. The developers should fix it. Disabling leak blocking for that app will allow it to work again. If the app can't get protected sockets right, it probably isn't preventing leaks in the first place.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Android provides VPN apps the capability to protect sockets that should bypass
the tunnel and leak blocking protection. It is then expected that any socket
that is not protected should not get a bypass. This is clearly documented and
easy for VPN app developers to implement. However, Android decided that some VPN
apps might forget to protect their sockets and added an exemption that allows
the VPN app to bypass leak blocking protection, even for unprotected sockets. As
a result of this exemption, the VPN app has no way to force traffic through the
tunnel, so anything it wishes to send through the tunnel is subject to being
leaked.
This change removes the exemption. If a VPN app breaks due to this change it is,
by definition, a broken app that was being saved by a workaround. The developers
should fix it. Disabling leak blocking for that app will allow it to work again.
If the app can't get protected sockets right, it probably isn't preventing leaks
in the first place.
GrapheneOS/platform_packages_modules_NetworkStack#17
GrapheneOS/platform_packages_modules_Connectivity#38
GrapheneOS/os-issue-tracker#5273