FdoSecrets: warning when client executable path can't be determined #6459
Comments
|
Hmm, come to think of it, since these prompts were added in #5747 , which is marked for 2.7.0, that would make this a pre-release bug, wouldn't it? |
droidmonkey
added a commit
that referenced
this issue
Oct 1, 2021
* Fixes #6459 Improves the overall handling of FdoSecrets showing client executable paths to the user. It does the following: * Check executable file existence as described in [RFC] fdosecrets: add optional confirmation to secret access (#4733) * Show application PID and dbus address in the client list * When the executable file is inaccessible, depending on where the client name is shown: * when shown inline, e.g. in notification text, where space is limited, clearly say that the path is invalid * when shown in auth dialog, show warning and print detailed info about the client * when shown in the client list, draw a warning icon Co-authored-by: Jonathan White <support@dmapps.us>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When an FdoSecrets client requests access to the DB, KPXC attempts to determine its executable path for authorization by the user. Sometimes, the executable path can't be determined (e.g. when
/proc/$pid/exeis inaccessible). In that case:Current Behavior
The executable path is not displayed in the authorization prompt (based on the PR discussions; I haven't tested in practice).
Expected Behavior
Show a bright warning instead of the missing executable path: "Client executable path could not be determined."
Context
A missing executable path is easy to miss in a hurry. A bright warning would draw user attention.
A counter-argument is that providing this warning may induce a false sense of security when the executable path is determined successfully. I'm not sure which is the lesser evil. But I would argue that the whole point of these authorization prompts is to detect when a suspicious process attempts to access the DB. If the user isn't aware that the executable path can be spoofed, they already provide a false sense of security as it is.
Displaying a warning in both cases (path determined vs undetermined) wouldn't be any better then not displaying them at all: the two cases would appear too similar to an inattentive user.
This may make more sense together with client fingerprinting (#6458). If we can't determine the executable path, we can't obtain its fingerprint.
Steps to Reproduce
/proc/$pid/exeis inaccessible, e.g. by callingprctl(PR_SET_DUMPABLE, 0)./proc/$pid/exe).Alternative:
Same as above, but instead of creating a special test client, add temporary debug code that pretends the
/proc/$pid/exeis inaccessible.Extra Info
Operating system: Linux
KPXC version: 2.7.0
(Reporting based on the PR discussions only.)
The text was updated successfully, but these errors were encountered: