Created attachment 169098 [details] Admin prompt with details when installing software in KDE discover SUMMARY The admin password dialog seems potentially fundamentally unsafe and like a significant downgrade to e.g. Windows UAC. I might be wrong on this one, but let me explain what I would expect the admin dialog to do so it's safe, and maybe that will help you decide whether I'm onto something here or not. Here is what I would the admin password dialog to provide which it doesn't, which ultimately seem to make it suspectible to trivial forgery attacks where just any application can grab the admin password and do whatever it wants, even with flatpak sandboxing and Wayland: 1. The admin dialog should at least give me the most vague chance to possibly figure out what process asks for permission because otherwise, any other process could try to just randomly launch a common admin password dialog and hope the user assumes it is legitimate without realizing it is from a completely different requesting process as usual. From all instances I've found, see attached screenshots, this is never the case. To make this clear on Linux, I think the following info would be required in the "Details" section: 1. at the very least the requesting process's initial exact launch command with full arguments, 2. possibly the process PID, 3. possibly the requesting process's current effective user id and user name. Windows UAC does this by showing the "Program location" on disk if you click "Show details". The KDE admin prompt doesn't seem to show any info here. For what it's worth, the "ID" and "vendor" it shows seem useful but not like it would allow most admins to figure out what group of processes would actually have the permission to request via this ID+vendor and whether that may be an impostor app or not. Therefore, these seem useful as additional indicators but not good enough. My apologies if that is incorrect. 2. The admin dialog should be visually distinct from whatever a program could launch as a fake, and/or allow using some keyboard combination to identify it's the "real" one. This would be possible for example if all the desktop was overlayed and dimmed including the task bar (which Windows UAC can be configured to do, and KDE doesn't do) and by optionally offering requiring something like pressing CTRL+ALT+DEL before confirming UAC which needs to be a combination that can't be grabbed by any non-admin apps and therefore if it is pressed and advances the UAC dialog you know it's the real one (which KDE doesn't seem to offer as an option either but Windows UAC does). This would also be made even safer by requiring an opt-in prompt for fullscreen from any flatpak sandboxed application, such that a screenshot of the desktop can't be taken and then modified on-the-fly to show the dialog with dim in front to fake it, since it would require a fullscreen prompt that would make you aware something is being overlayed. STEPS TO REPRODUCE 1. Look at admin prompts, see attachments which has the example of virt-manager requiring admin pw, and a "Terminal - Super User Mode" requiring admin pw. OBSERVED RESULT It's not possible to rule out a forgery of the dialog (= 100% fake dialog prompted by other app), and it's not possible to rule out an unexpected app prompting instead of the expected one (= real dialog but prompted by different app than usual, unexpectedly elevating the wrong one). EXPECTED RESULT Forgery and app mixups are at least on a basic level somewhat ruled out for attentive users that make use of all the information shown in the dialog. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: openSUSE Slowroll (available in About System) KDE Plasma Version: plasmashell 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 ADDITIONAL INFORMATION
Created attachment 169099 [details] Admin prompt for virtual machine privileged access in virt-manager
Created attachment 169100 [details] Admin prompt for a super user terminal (not sure if that's an openSUSE specific dialog or also a KDE one)
Adding the executable seems like a sensible improvement. PID, maybe... I'm not sure that means anything to most people, as it would have to be manually cross-referenced with the app you expect. 99.999999% of people won't do that. Changing the styling would not help since a rogue app could simply emulate that style. Requiring a special key combination to be pressed would be disruptive and annoying Making the dialog system-modal in the style of UAC and GNOME would also be disruptive and annoying, and also and not actually provide any additional security. In the end security is a balance; if it gets in people's way too much, people find workarounds that remove all security. You don't make a house secure by putting 12 locks on the front door. Those with heightened security needs should provide the requisite hardening for themselves.
> PID, maybe... I'm not sure that means anything to most people, as it would have to be manually cross-referenced with the app you expect. 99.999999% of people won't do that. For what it's worth, I think the point for PID would be that for the 1% of cases where it looks actually suspicious, people then have a chance to cross-reference it. Although I suppose that would also require to be able to look at a task manager in some way via a global shortcut like windows does. But without that it's still useful because the admins that are both going to care about what is prompting them to that level, are also more likely to be the ones knowing that the TTY exists. There's also the chance of keeping the PID in mind, pressing cancel, *then* checking the task manager, then repeating the task to get the prompt again and to then know that it's indeed what you thought it was. TL;DR: I think most people aren't going to check any of the detail info ever. But I don't think the natural conclusion is to then not add it.
> Requiring a special key combination to be pressed would be disruptive and annoying Making the dialog system-modal in the style of UAC and GNOME would also be disruptive and annoying, and also and not actually provide any additional security. The point is doing both actually does provide significant additional security, unless I am mistaken: The special key prompt makes sure that it's actually the system or compositor showing this dialog and not a rogue fullscreen app, and because it's system-modal you then also know that while it's showing no other app can somehow get in front and confuse you. It's why Windows UAC offers this mode, and at least as an option I think it makes sense. I know it sounds cumbersome, but how else would a rogue app be effectively prevented from fooling the user here? All information shown in the dialog including the PIDs is usually available to most processes on the system, so forging the dialog isn't exactly difficult right now. That seems like it renders the whole idea of an elevation dialog somewhat moot, however.
Small update: > The admin dialog should be visually distinct from whatever a program could launch as a fake I recently learned at leas this small part exists, it's called "Dim Screen for Administrator Mode" in "Desktop Effects". However, it doesn't seem to be enabled by default. I propose that it might be worth considering to enable it by default, while of course retaining the option to disable it if desired.