the privilege escalation dialog is mostly a windows 10 copy, but just shows: allow dbus.something.something"? the name is always meaningless and have no parameters. and there's zero way to get more information. windows at least shows the binary or PowerShell command plus the arguments.
I think that either the terminal program should print something like a PIN which is repeated in the window to cross-check, or the window should be able to use some restricted window manager feature (like Windows' fullscreen greying out thing) to prove that it's not just a random Qt/GTK window from an attacker's script.
I agree this situation needs improving, the problem just runs much, much deeper.
On the other hand: if an attacker placed a modified sudo that steals your password in ~/.local/bin, it would also be Game Over. Much of the current security model breaks as soon as the attacker has code execution.
EDIT: I'd also like to highlight this:
> or the window should be able to use some restricted window manager feature (like Windows' fullscreen greying out thing) to prove
Your Wayland compositor also runs in userspace. Even if it is supposed to check that some calls come from euid 0, an attacker may be able to circumvent them if the attacker runs in the same context as the compositor. Again, the security problem runs very deep.
The age-old xkcd about linux being secure only about your video card driver is still true to this age, with no clear sign of improvement.
Also, frankly I don’t understand why there is no more cross-pollination between android and linux userspace - the former has actually solved this issue properly.
I’m afraid the answer is that “it is not written in c”.
I don't think it has anything to do with it. Android's security comes from design, not language. Each application runs under its own UID and not all applications can draw arbitrary content on your screen, for example.
Those things could be on the Linux Desktop. And maybe flatpak will bring it to us. But for now I can already hear the screeching about "freedom" and "the Unix philosophy".
"This application requires storage permission. Grant ?"
Yes. Comes from design. /s
No FOSS desktop is even close to offering this. The windows 'greying out thing' is an entirely separate desktop instance, for example. A lot of security consideration was put into designing it. I don't think any FOSS desktop is working on anything even remotely similar, which is a shame.
The only true security feature I remember was implemented in Windows many years ago. After you got security prompt, you would need to press Ctrl+Alt+Delete and type password there. Supposedly only Windows itself could handle that combination.
Because you would be able to alt+tab to other tasks, and that application would be able to still execute code as it was able to before. It's not any kind of security 'behind the scenes'.
> The only true security feature I remember was implemented in Windows many years ago.
Or perhaps you didn't realize all the engineering that was taking place behind just what you see. This[0] blog post gives a good overview of some of the security architecture that went into making that elevation prompt.
Honestly, MS has been leading the pack in OS security for some time. They are leagues ahead of MacOS and Linux.
[0] https://learn.microsoft.com/en-us/archive/blogs/uac/user-acc...
It's all security theater.
You wouldn't be able to switch to another application is the point. What you suggest greying out, would easily allow other applications to hijack that prompt or replace it with their own.
That's a large part of what 'Secure Desktop' aims to prevent, and it succeeds at doing so.
> If the policy setting is set to Prompt for credentials, malware imitating the credential prompt might be able to gather the credentials from the user. However, the malware doesn't gain elevated privilege and the system has other protections that mitigate malware from taking control of the user interface even with a harvested password.
So just knowing the credentials is not enough, they have to be used in the right context (the secure desktop).
In contrast, on Linux, if you put a shell script in the users $PATH called 'sudo' that simply captures their password, you can (assuming the default PAM configuration) immediately use that to elevate privileges anytime you want with absolutely no intervention whatsoever. Because the password not only authenticates you, it authorizes you as well.