GNOME Bugzilla – Bug 688351
Authentication dialogs do not explain where they come from
Last modified: 2021-07-05 14:41:25 UTC
While using GNOME Shell, I received the following message, completely out of the blue, in the form of a big, invasive, system-modal popup: "Authentication is required to run /bin/sh as the super user [Cancel] [Authenticate]" There is nothing, anywhere, to tell me what application I am granting this permission to. Meanwhile, the bulk of the dialog, telling me what I am allowing $NamelessApplication to do, is unhelpful. A sensible model for trust takes into account applications. If my web browser is asking for my password to do something, I should be pretty concerned. If a backup application is making the same request, I should be less concerned. As it is, the dialog does not express in any meaningful way _who_ is making a request. It could be that backup tool, or it could be some malware about to gain control of my system. Meanwhile, the system-modal popup offers no reasonable way out: I can either enter my password, or cancel. Cancelling has a high chance of breaking whatever application needs the authentication, and there is no way to hide the dialog and make sure I know what is going on. Certainly, I can usually tell where an authentication dialog came from based on when it appears (for example, right after I click "Start Self-test" in Disks), but that is a feeble basis for security.
Do you have a screenshot or camera-shot? Modals should only appear in response to user input. We have talked about adding a policy layer to enforce this but it is tricky and have tried to rely on good behavior from applications. Obviously this application is behaving poorly. What is it from? Cancel is the reasonable way out. It should never break anything. Apps should be robust against that.
That one was from deja-dup. I should definitely file a bug report against it: it asked for authentication halfway through restoring files. Do you know if it's possible for the shell to say what process is making the request? That would have helped in this case :)
(In reply to comment #2) ... > Do you know if it's possible for the shell to say what process is making the > request? That would have helped in this case :) Seems like a good idea to me.
That is certainly a deja-dup bug. Needing authentication halfway through sounds terrible to begin with - not to mention asking for a root password. But so be it. I'm assuming there is an application window open while it is restoring files since how else did you ask it to restore files. And I'm also assuming you wouldn't want to stare at the progress bar in said app for very long and switched to something else. In that case I'd expect it to use a notification to alert you that either the restore has finished successfully or that there was a problem restoring your files. When and if you respond to that notification and return to the application it would present you with the relevant information. In the event of an error I would expect to see some form of "Retry" button. Where in response to that there may be a prompt for more information (like the credentials). In no circumstances should background applications be using system modal dialogs. Showing the application name doesn't sound like a good solution because they just shouldn't happen. What API are they using?
(In reply to comment #3) > (In reply to comment #2) > ... > > Do you know if it's possible for the shell to say what process is making the > > request? That would have helped in this case :) > > Seems like a good idea to me. Except it won't do much good in this case I'm afraid, because ... (In reply to comment #4) > Showing the application name doesn't sound like a good solution because they > just shouldn't happen. What API are they using? ... they are spawning a command line like 'pkexec sh "/tmp/Déjà Dup-$random"'. *sigh*
Was a bug filed against deja-dup about this?
One of the biggest dark spots on the 3.12 release is the random authentication modal that comes up from time to time. There is no association with the application or service that is requesting it. I don't want to quickly jump into providing solutions, but the notification system does a good job of associating a message from applications that are in the background. We should perhaps never disrupt anyone with modal dialogs when the application requesting it isn't in the foreground (focused). A notification itself could be used for this scenario, if an application can't access data because a network resource is unavailable due to expired token/credentials, it should trigger a notification rather than a modal auth dialog.
*** Bug 697668 has been marked as a duplicate of this bug. ***
*** Bug 709430 has been marked as a duplicate of this bug. ***
(In reply to William Jon McCann from comment #1) > Do you have a screenshot Ha... no way for the user to get to any screenshot application in such cases, as all typing to other windows has been cordoned off by this omnipotent question box. Bug #784269.
(In reply to Dan Jacobson from comment #10) > (In reply to William Jon McCann from comment #1) > > Do you have a screenshot > Ha... no way for the user to get to any screenshot application in such > cases, as all typing to other windows has been cordoned off by this > omnipotent question box. Bug #784269. It actually says: "Do you have a screenshot or camera-shot?" So you could have taken a picture with a phone or digital camera. Also, the message box as triggered in this bug report doesn't eat the screenshot button. You can run "pkexec sh foo", press "PrintScreen" on the dialogue, and cancel.
Anyway we know what Polkit authorization dialogs are, we don't need to see a screenshot or camera shot.
(In reply to Bastien Nocera from comment #11) There is no screenshot button because I'm using nodm / icewm / epiphany and also even though I can switch to another window, I cannot type anything there, because all typing into other windows has been disabled. All I can do is ALT-CTRL-F1 to leave X windows all together. So yes, one, gasp, must use a camera.
(In reply to Dan Jacobson from comment #13) > (In reply to Bastien Nocera from comment #11) > There is no screenshot button because I'm using nodm / icewm If you are seeing gnome-shell's system-modal polkit dialogs, then you are using gnome-shell as window-manager (not nodm / icewm / whatever).
(In reply to Florian Müllner from comment #14) Bug 784269 is what I am seeing.
All right, I no longer know what Dan is seeing. We really do need to see a picture. I thought this was the gnome-shell keyring prompt. Guess: maybe gcr has its own version of this prompt that it is trying to display.
It does, but it's a regular GTK+ dialog: https://git.gnome.org/browse/gcr/tree/ui/gcr-prompt-dialog.c
Yeah, this sounds like a separate discussion to be had in #784269 to me. The original bug report is about the system modal dialogs drawn by GNOME Shell. Particularly how their design can train users that it's okay to type in their password without question, as long as they are asked to by a big dark grey overlay. (Although not necessarily a problem in most setups. It's a bit uglier if your keyring is locked at login). Solutions may overlap slightly… Question, while I'm here, (and maybe I can pop this into my weekend coding list above some of the silly web stuff that's taken over for me): is there a way to safely identify which application has sent these sorts of requests? Like, is this mainly a design thing where we could explore some different approaches, or do we have some deeper technical conundrums in the way as well?
(In reply to Dylan McCall from comment #18) > Yeah, this sounds like a separate discussion to be had in #784269 to me. The > original bug report is about the system modal dialogs drawn by GNOME Shell. Yes. Whoops, I thought this was that bug. (In reply to Dylan McCall from comment #18) > is there a way to safely identify which application has sent these sorts of requests? > Like, is this mainly a design thing where we could explore some different > approaches, or do we have some deeper technical conundrums in the way as > well? I don't know. What we need is to allow applications to register some user-friendly name, and attest that they are the legitimate application with this name. I suspect this level of attestation is not currently possible.
(In reply to Michael Catanzaro from comment #19) > I don't know. What we need is to allow applications to register some > user-friendly name, and attest that they are the legitimate application with > this name. I suspect this level of attestation is not currently possible. Not generally as far as I can see. polkitd can determine the PID of the initiating process and includes that in the request - if there are any open windows associated with that process, then we can match the request to an application. Of course that only helps with applications that are already well-behaving, so not sure how much sense that makes. I'll attach a patch in case we want this anyway, as it at least allows to discard running applications when the information is missing from the dialog ...
Created attachment 354649 [details] [review] polkit-agent: Include subject PID in ::initiate It is not always clear what triggered a particular polkit request, so displaying more information to the user is desirable. Unfortunately the information provided by polkitd is rather sparse, and is usually limited to subject- and caller PID. Still that's better than nothing, so include the PID of the initiating process in the signal parameters.
Created attachment 354650 [details] [review] polkitAgent: Indicate which application initiated a request Now that the ::initiate signal may contain the PID of the initiating process, we can try to resolve it to an application and use that to indicate where a request originated. This should work for well-behaved applications that only ask for permissions in response to a user action, but unfortunately not when it would be most useful, that is when the dialog is triggered "out of nowhere" by a background service ...
Review of attachment 354650 [details] [review]: ::: js/ui/components/polkitAgent.js @@ +409,3 @@ _onInitiate: function(nativeAgent, actionId, message, iconName, cookie, subjectPid, userNames) { + let pid = parseInt(subjectPid); + let app = pid != NaN ? this._windowTracker.get_app_from_pid(pid) : null; My worry is that it seems likely that a malicious application could spoof another here, correct? E.g. imagine: # ~/.local/share/applications/malicious.desktop Exec=~/.local/bin/malicious Name=Web Icon=org.gnome.Epiphany It might be more desirable to show no information at all than to show potentially-untrustworthy information in a security prompt. On the other hand, I suppose if the malicious app already has control of the filesystem, the user has already lost. So this might not be a valid concern at all. I wonder what other clever tricks could be used to subvert this functionality.
(In reply to Michael Catanzaro from comment #23) > + let pid = parseInt(subjectPid); > + let app = pid != NaN ? this._windowTracker.get_app_from_pid(pid) : > null; > > My worry is that it seems likely that a malicious application could spoof > another here, correct? E.g. imagine: > > # ~/.local/share/applications/malicious.desktop > Exec=~/.local/bin/malicious > Name=Web > Icon=org.gnome.Epiphany That works, but probably not quite how you imagine - we don't do app matching based on executable name, so to work, 'malicious' needs an open window with: - _NET_WM_PID pointing to the process making the polkit request - WM_CLASS set to 'malicous' (or some other bit we use to match windows to apps, like _GTK_APPLICATION_ID) At that point, the spoofing isn't limited to the polkit request - it will show up as the legit app everywhere: app picker, alt+tab, overview search, app menu, ... if it doesn't use a separate .desktop ID, it will even get grouped together with legit app windows. To me this sounds like we already lost big time ...
(In reply to Michael Catanzaro from comment #23) > + let app = pid != NaN ? this._windowTracker.get_app_from_pid(pid) : > null; > > My worry is that it seems likely that a malicious application could spoof > another here, correct? Mmmh, there's actually a more worrying case - if the malicious app can open an xserver connection, it could change the _NET_WM_PID property of an open window to point to its own PID. No need for a separate .desktop file or open window in that case. This is something we could address by basing the PID => app matching on the client PID instead of the X11 property. That would have the additional benefit of also working on wayland, and pointing to the correct "outside" PID when being launched with a private PID namespace (the flatpak case).
(In reply to Michael Catanzaro from comment #23) > Review of attachment 354650 [details] [review] [review]: > > ::: js/ui/components/polkitAgent.js > @@ +409,3 @@ > _onInitiate: function(nativeAgent, actionId, message, iconName, cookie, > subjectPid, userNames) { > + let pid = parseInt(subjectPid); > + let app = pid != NaN ? this._windowTracker.get_app_from_pid(pid) : > null; > > My worry is that it seems likely that a malicious application could spoof > another here, correct? E.g. imagine: > > # ~/.local/share/applications/malicious.desktop > Exec=~/.local/bin/malicious > Name=Web > Icon=org.gnome.Epiphany If somebody has geoclue agent déjà-vu, that's all as expected. CC:ing Zeeshan and Matthias
(In reply to Michael Catanzaro from comment #16) > All right, I no longer know what Dan is seeing. We really do need to see a > picture. Do you still need it?
(In reply to Dan Jacobson from comment #27) > (In reply to Michael Catanzaro from comment #16) > > All right, I no longer know what Dan is seeing. We really do need to see a > > picture. > Do you still need it? It might be helpful to post it in the *other* bug, but it's not necessary because we figured out it's coming from gcr. Please keep in mind this bug is the gnome-shell issue, which does not affect you because you are not using gnome-shell.
OK. Screenshot: attachment 354664 [details].
I made it with $ import -pause 222 -window root /tmp/m.jpg & epiphany some_site.com the only way to do it is with -pause, as by that time one cannot type to other windows.
Uploaded the patches to gitlab: https://gitlab.gnome.org/GNOME/gnome-shell/merge_requests/43
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.