[policykit-kde-agent-1] [Bug 486453] Show more metadata about the initiating process to help people verify what exactly requested authentication
https://bugs.kde.org/show_bug.cgi?id=486453 --- Comment #6 from Ellie --- 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. -- You are receiving this mail because: You are watching all bug changes.
[policykit-kde-agent-1] [Bug 486453] Show more metadata about the initiating process to help people verify what exactly requested authentication
https://bugs.kde.org/show_bug.cgi?id=486453 --- Comment #5 from Ellie --- > 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. -- You are receiving this mail because: You are watching all bug changes.
[policykit-kde-agent-1] [Bug 486453] Show more metadata about the initiating process to help people verify what exactly requested authentication
https://bugs.kde.org/show_bug.cgi?id=486453 --- Comment #4 from Ellie --- > 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.99% 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. -- You are receiving this mail because: You are watching all bug changes.
[policykit-kde-agent-1] [Bug 486453] Show more metadata about the initiating process to help people verify what exactly requested authentication
https://bugs.kde.org/show_bug.cgi?id=486453 Nate Graham changed: What|Removed |Added Keywords||usability Ever confirmed|0 |1 Status|REPORTED|CONFIRMED Summary|Admin password dialog seems |Show more metadata about |potentially fundamentally |the initiating process to |unsafe and like a |help people verify what |significant downgrade to|exactly requested |e.g. Windows UAC|authentication CC||n...@kde.org Severity|normal |wishlist --- Comment #3 from Nate Graham --- 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.99% 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. -- You are receiving this mail because: You are watching all bug changes.
