secure paste: add clipboard access policy and grants - #435
Open
inthewaves wants to merge 9 commits into
Open
Conversation
Secure paste lets users prevent third-party apps from reading clipboard contents on their own while keeping Paste working when they choose it. Add a device-wide default and per-app controls, keep access allowed by default for compatibility, and enforce the policy centrally in the clipboard service. Apps can still read the current clipboard item when it was copied by their own app identity. This preserves in-app copy workflows without allowing access to items copied by a different app identity. Apps set to Paste only can still tell that a clipboard item is available and inspect its MIME types, copy timestamp, and styled text state. TextView.canPasteAsPlainText() uses the MIME types and styled text state to offer Paste as plain text without reading the content. Keep the timestamp available for compatibility. Hide the label, extras, semantic classification, and ClipData payload. Represent an explicit Paste with a short-lived grant tied to the destination app, the specific clipboard, and its current item. Existing package identity, focus, AppOps, and device lock checks continue to apply. Later commits add authorization paths for the selection toolbar, input methods, accessibility services, and keyboard shortcuts. Co-authored-by: inthewaves <inthewaves@pm.me>
Users who choose Paste from the selection toolbar should not need to give the focused app ongoing clipboard access. Authorize that app when the toolbar dispatches Paste. SystemUI renders the remote toolbar outside the destination app. Derive the destination from the toolbar host and current input target, and verify their identity before granting access instead of trusting an app identity reported through the renderer callback. Co-authored-by: octocorvus <admin@octocorvus.dev>
Users should receive the same secure paste behavior when their keyboard offers Paste. Authorize the focused app before the current input method forwards the standard Paste action to it. Accept authorization only from the active input method and only for the input connection currently served by system_server. Neither an app nor an input method can use this path to choose a different destination. Co-authored-by: octocorvus <admin@octocorvus.dev>
Users can invoke an editor's Paste action through an accessibility service. Give the focused app the same temporary clipboard access as other user-initiated Paste actions. Honor the action only from a currently bound service whose caller identity matches its connection, and only when it targets the input-focused window on that display. Resolve the destination from the registered accessibility connection rather than allowing the service to name an app. Co-authored-by: octocorvus <admin@octocorvus.dev>
Keep the hardware Paste key and the standard Ctrl-V and Shift-Insert shortcuts working for apps set to Paste only. Authorize the focused app before delivering the initial, uncancelled key-down event. Derive the destination from the focused input target. Reserve paste chords from custom gesture assignment so the same key event cannot both authorize Paste and invoke an unrelated global action. The current SystemUI customizer requires the Meta key (for example, the Windows logo key) and does not offer Paste as a customizable action, so it cannot create or remap these chords. This still changes the privileged custom gesture API: Ctrl-Shift-V, Shift-Insert, and the hardware Paste key were previously accepted, and existing mappings using them will be rejected when gestures are reloaded. Ctrl-V was already reserved. Co-authored-by: octocorvus <admin@octocorvus.dev>
Verify that users can restrict direct clipboard reads without breaking explicit Paste actions. Use
separate apps, apps sharing an identity, and privileged apps so the suite covers the same package
and process boundaries as real callers, including access to an app identity's own clipboard
contents, compatible metadata access, and the global and per-app policy.
Exercise Paste through framework widgets, Compose, the remote toolbar, an input method,
accessibility, and hardware key gestures. Virtual device coverage uses a separate writer and checks
that authorization stays with the clipboard and display where the user initiated Paste.
The privileged coverage uses the SecurePasteTestSystemApp module. Add it to PRODUCT_PACKAGES_DEBUG
in build/make so userdebug test images install the system app before the suite runs.
The secure-paste-compat-default-allow group checks that secure paste preserves existing AOSP
clipboard behavior when global clipboard access is allowed by default. It runs the relevant platform
and CTS coverage to catch compatibility regressions for devices that retain that policy.
Test: atest --test-mapping frameworks/base/tests/SecurePasteTests:gos-postsubmit
Test: adb shell settings put global allow_clipboard_read 1 &&
atest --test-mapping \
frameworks/base/tests/SecurePasteTests:secure-paste-compat-default-allow
An app set to Paste only can use clipboard metadata to decide whether to offer Paste. If it then tries to read the payload without an explicit Paste action, the read fails without telling the user why. Show an optional message when secure paste blocks an otherwise eligible read, and enable it by default. Users can turn the message off independently from successful clipboard access messages. Avoid repeated messages by allowing one notification attempt per app identity and clipboard generation, no more than once per minute. Both a new generation and the elapsed minute are required. Setting the clipboard again starts a new generation even when the contents have not changed, but it does not bypass the time limit.
KeyGestureControllerTests enables every optional system gesture at class scope. On product builds with disabled read-only optimized flags, SetFlagsRule skips every method before its test body runs, including tests unrelated to those gestures. Scope keyboard backlight, contextual input and contextual cursor overrides to the parameterized gesture tests whose data contains them. Other tests can then run against the product defaults, while the relevant gesture tests retain their overrides on builds where the flags are mutable.
FrameworksCoreTests targets the current platform SDK. That enables a compatibility change which disables TextView's legacy autofill fallback to InputConnection.commitContent() for apps targeting Android T and newer. Disable the change for the receive content tests so their positive and negative cases exercise the fallback instead of stopping at the target SDK gate. Keep TextView test content below the system bars so taps and long presses reach the editors. Require the floating toolbar to exist before checking that Paste as plain text is absent. Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest Test: atest FrameworksCoreTests:android.widget.TextViewReceiveContentTest
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
2 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.
Closes GrapheneOS/os-issue-tracker#2917
Depends on:
Secure paste lets users prevent third-party apps from reading clipboard contents on their own while
keeping Paste working when they choose it. Add a device-wide default and per-app controls, keep
access allowed by default for compatibility, and enforce the policy centrally in the clipboard
service.
Apps can still read the current clipboard item when it was copied by their own app identity. This
preserves in-app copy workflows without allowing access to items copied by a different app identity.
Apps set to Paste only can still tell that a clipboard item is available and inspect its MIME types,
copy timestamp, and styled text state. TextView.canPasteAsPlainText() uses the MIME types and styled
text state to offer Paste as plain text without reading the content. Keep the timestamp available
for compatibility. Hide the label, extras, semantic classification, and ClipData payload.
Represent an explicit Paste with a short-lived grant tied to the destination app, the specific
clipboard, and its current item. Existing package identity, focus, AppOps, and device lock checks
continue to apply. Later commits add authorization paths for the selection toolbar, input methods,
accessibility services, and keyboard shortcuts.
Supported trusted paste actions that are always allowed in apps set to Paste only:
The
secure-paste-compat-default-allowgroup checks that secure paste preserves existing AOSPclipboard behavior when global clipboard access is allowed by default. It runs the relevant platform
and CTS coverage to catch compatibility regressions for devices that retain that policy.
Test:
atest --test-mapping frameworks/base/tests/SecurePasteTests:gos-postsubmitTest:
adb shell settings put global allow_clipboard_read 1 && atest --test-mapping frameworks/base/tests/SecurePasteTests:secure-paste-compat-default-allow