193

Sometimes, Ubuntu shows the following window:

Screen shot of "Authenticate" dialog box asking for password

This window can be caused by some background processes running, such as an automatic update, or a process which reports bugs to Canonical which manifests itself this way:

Screen shot of "System program problem detected" query box

Since those are background processes, the first window is not shown in response to an action I performed myself, in a situation where I was expecting the system to ask me for the password. This means that:

  • From the perspective of the user, there is no guarantee that the prompt comes from the operating system; it could be any malicious program which had only a limited permission to show a window, and which, by prompting for my password, will gain unlimited access to the entire machine.

  • By prompting the user for a password regularly, the system teaches the user that giving his system password whenever some application asks for it is a perfectly natural thing to do.

My questions are:

  • Is there any safety mechanism in Linux in general or Ubuntu specifically that prevents any application from displaying a dialog which looks identical to the system one, asking me for my password?

  • How should such windows be designed to increase the safety of the user? Why not implement a system similar to Windows' Ctrl+Alt+Del on logon?

200_success
  • 2,144
  • 2
  • 15
  • 20
Arseni Mourzenko
  • 4,644
  • 6
  • 20
  • 30
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/64019/discussion-on-question-by-arseni-mourzenko-isnt-ubuntus-system-prompt-for-my-p). – Rory Alsop Aug 17 '17 at 20:06

6 Answers6

193

Your points are all good, and you are correct, but before we get outraged about it we need to remind ourselves how the linux security model works and what it's designed to protect.

Remember that the Linux security model is designed with a multi-user terminal-only or SSH server in mind. Windows is designed with an end-user workstation in mind (but I've heard that the recent generation of Windows is more terminal-friendly). In particular, Linux convention does a better job of sandboxing apps into users, while in Windows anything important runs as System, while the Linux GUI (X Server) sucks at security, and the Windows GUI has fancy things like UAC built-in. Basically, Linux is (and always has been) a server first and a workstation second, while Windows is the other way around.


Security Models

As far as "the OS" (ie the kernel) is concerned, you have 7 tty consoles and any number of SSH connections (aka "login sessions") - it just so happens that ubuntu ships with scripts to auto-start the GUI on the tty7 session, but to the kernel it's just another application.

Login sessions and user accounts are sandboxed quite nicely from each other, but Linux takes a security mindset that you don't need to protect a user from them-self. In this security model, if your account gets compromised by malware then it's a lost cause, but we still want to isolate it from other accounts to protect the system as a whole.

For example, Linux apps tend to create a low-privilege user like apache or ftp that they run as when not needing to do rooty things. If an attacker manages to take control of a running apache process, it can muck up other apache processes, but will have troubles jumping to ftp processes.

Note that Windows takes a fundamentally different approach here, largely through the convention that all important things run as System all the time. A malicious service in Linux has less scope to do bad things than a malicious process running as System, so Windows needs to go to extra efforts to protect someone with admin rights from "them-self".

GUI environments and an X Server that was not designed for security throw a wrench into this security model.


Gnome gksudo vs Windows UAC, and keyloggers

In Windows, when a user-process requests privilege escalation, the kernel throws up a special protected prompt whose memory and keyboard / mouse bus is isolated from the rest of the rest of the desktop environment. It can do this because the GUI is built-in to the OS. In Linux, the GUI (X server) is just another application, and therefore the password prompts belong to the process that invoked them, running as you, sharing memory permissions and an input bus with every other window and process running as you.

The root prompt can't do the fancy UAC things Iike lock the keyboard because those either need to be root already, or require totally re-designing the X server (see Wayland below). A catch-22 that in this case is a downside of separating the GUI from the kernel. But at least it's in keeping with the Linux security model.

If we were to revise the security model to clamp down on this by adding sandboxing between password prompts and other processes running as the user in the same GUI session, we could have to re-write a great many things. At the least, the kernel would need to become GUI aware such that it is capable of creating prompts (not true today). The other go-to example is that all processes in a GUI session share a keyboard bus.

Watch me write a keylogger and then press some keys in a different window:

➜  ~ xinput list  
⎡ Virtual core pointer                      id=2    [master pointer (3)]
⎜   ↳ Virtual core XTEST pointer            id=4    [slave  pointer  (2)]
⎜   ↳ Logitech K400 Plus                    id=9    [slave  pointer  (2)]
⎜   ↳ ETPS/2 Elantech Touchpad              id=13   [slave  pointer  (2)]
➜  ~ xinput test 9
key release 36 
key press   44 
hkey release 44 
key press   40 
ekey release 40 
key press   33 
lkey release 33 
key press   33 
lkey press   39 
okey release 33 
key release 39 
key press   66 
key press   31

Any process running as you can sniff the password in another process's prompt or terminal and then call sudo on itself (this follows directly from the "no need to protect you from you" mindset), so increasing the security of the password prompts is useless unless we fundamentally change the security model and do a massive re-write of all sorts of things.

(it's worth noting that Gnome appears to at least sandbox the keyboard bus on the lock screen and new sessions through "Switch Users" as things typed there do not show up in my session's keyboard bus)


Wayland

Wayland is a new protocol that aims to replace X11. It locks down client applications so that they cannot steal information or affect anything outside of their window. The only way the clients can communicate with each other outside of exterior IPC is by going through the compositor which controls all of them. This doesn't fix the underlying problem however, and simply shifts the need for trust to the compositor.


Virtualization and Containers

If you work with cloud technologies, you're probably jumping up and down saying "Docker is the answer!!". Indeed, brownie points for you. While Docker itself is not really intended to enhance security (thanks @SvenSlootweg), it does point to using containerization and / or virtualization as a forward that's compatible with the current Linux architecture.

Two notable linux distributions that are built with inter-process isolation in mind:

Qubes OS that runs user-level apps inside multiple VMs separated into "security domains" such as work, banking, web browsing.

Android that installs and runs each app as a separate low-privilege user, thus gaining process-level isolation and file-system isolation (each app is confined to its own home directory) between apps.


Bottom Line: From the perspective of an end-user, it's not unreasonable to expect Linux to behave the same way as Windows, but this is one of those cases where you need to understand a bit about how the underlying system works and why it was designed that way. Simply changing the implementation of the password prompts will not accomplish anything so long as it is owned by a process owned by you. For Linux to get the same security behaviours as Windows in the context of a single-user GUI workstation would require significant re-design of the OS, so it's unlikely to happen, but things like Docker may provide a way forward in a more Linux-native way.

In this case, the important difference is that Linux is designed at the low level to be a multi-user server and they make the decision not to protect a user from them-self, while Windows is designed to be a single-user workstation, so you do need to have inter-process protections within a login session. It's also relevant that in Windows the GUI is part of the OS, while in Linux the GUI is just another user-level application.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
  • 85
    I couldn't figure out how to fit this into the body, but [mandatory xkcd](https://xkcd.com/1200/) – Mike Ounsworth Aug 13 '17 at 21:25
  • 16
    I think "at the low level" both OSs are full-fledged, totally comparable multi user servers. It's the "GUI is part of Windows (!)" vs. "the X session is just another user program" part which is important. – Peter - Reinstate Monica Aug 14 '17 at 04:49
  • 12
    While all of this is factually correct, I see little relationship to the question... – AnoE Aug 14 '17 at 08:01
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/63876/discussion-on-answer-by-mike-ounsworth-isnt-ubuntus-system-prompt-for-my-passw). – Rory Alsop Aug 15 '17 at 18:31
  • 1
    _Remember that the linux security model is designed with a multi-user headless or SSH server in mind, and in this context Linux has more protections. Windows is designed with an end-user workstation in mind, and in this context Windows has more protections._ Where did you conclude this from? – jobukkit Aug 15 '17 at 19:01
  • 3
    @JopV. Mainly from my own experiences; the X server sucks at security, and while I'm not a Windows expert, it seems that it sucks at having multiple users logged into the GUI simultaneously and the convention that anything important runs as System rather than applying principle of least priviledge. I'm happy to have my opinion changed though. – Mike Ounsworth Aug 16 '17 at 13:04
  • 5
    "*I wouldn't be shocked if we start seeing Linux distros containerize web browsers and other high-risk applications in the coming years*" [Qubes](https://www.qubes-os.org/) does this. – Corey Ogburn Aug 16 '17 at 15:22
  • This answer should probably address Wayland's take on security and how it improves things (but ultimately just adds the compositor as another thing you should trust) – Timidger Aug 17 '17 at 05:37
  • @Timidger I actually don't know enough about Wayland to talk about it. Feel free to suggest an edit though. – Mike Ounsworth Aug 17 '17 at 11:55
  • 1
    @Will that would make code that runs directly in the compositor you don't trust (or code that might have bugs in it) safer. However you still need to trust the compositor implementation, because it's the main thing the clients are talking to. Put another way, if you imagine a compositor as the server and the windows/applications as the clients it doesn't matter if the server can't write to your home but it exposes whatever you type to any client, or let's a client draw anything anywhere and scrape the pixels from reportedly "trusted" applications. All input goes through the compositor. – Timidger Aug 18 '17 at 15:13
  • @Timidger As usual, what counts as "secure" is in the eye of the beholder and relative to what you're trying to protect ;) – Mike Ounsworth Aug 18 '17 at 15:15
  • 1
    It's unfortunate that this answer speaks of Docker as an isolation measure. __Docker does not provide secure isolation against malicious applications__, as this is out of scope for what Docker is designed for (isolating against accidental contamination of dependencies and such). Certain containerization technologies (OpenVZ, unprivileged LXC) *can* provide secure isolation, but Docker is certainly not one of them. Additionally, "containers" and "VMs" are not the same kind of thing. – Sven Slootweg Aug 18 '17 at 15:27
  • 1
    @SvenSlootweg I'm using (small c) container in the sense that all VMs are containers, but not all containers are VMs. The linked wikipedia article says _"In addition to isolation mechanisms, the kernel often provides resource-management features to limit the impact of one container's activities on other containers."_ That sounds like some level of secure isolation to me. – Mike Ounsworth Aug 18 '17 at 15:33
  • 1
    @MikeOunsworth "Some level" of it is not enough, though, and "isolation against malicious behaviour" vs. "isolation against accidental contamination / resource overuse" are two very different things. Docker only takes care of the latter, not the former, and is therefore *completely* insufficient when talking about malware. See also https://gist.github.com/joepie91/1427c8fb172e07251a4bbc1974cdb9cd#secure-isolation – Sven Slootweg Aug 18 '17 at 16:41
  • @SvenSlootweg Does that edit agree with your thoughts? – Mike Ounsworth Aug 18 '17 at 18:22
33

Is there any safety mechanism in Linux in general or Ubuntu specifically which prevents any application from displaying a dialog which looks identical to the system's one, asking me for my password?

Quick answer: No.

From the perspective of the user, there is no guarantee that the prompt comes from the operating system; it could be any malicious program which had only a limited permission to show a window, and by prompting for my password, will gain unlimited access to the entire machine.

If a malicious program is on the computer, it doesn't even matter what program is showing the dialog.
If it is the malicious program, well, as described in the next sentence, it doesn't even need to show you a dialog. If it is a legit program, the malicious program can "watch" the window and what you're typing there, in X server environments (the terminal is better).

Solution?

If you have reason to believe some program isn't trustworthy, sandboxing (VM or lesser things).

Else, not asking for passwords. That dialog is convenience for non-technical users. If you're concerned for security, or an organizations admin or similar, there's absoluetly no need to ever display a GUI password query. Configure the permissions of non-root user accounts properly (yes or no, but not asking), and do not use a desktop as root (because of that, and because it is an temptation to use root more often than necessary).

By prompting the user for password regularly, the system teaches the user that giving his system password whenever some application asks for it is a perfectly natural thing to do.

As described, just don't ask them. As admin, "your" users are supposed to have clearly defined permissions.

And, about auto updates as organization admin: Are you insane :) Seriously, don't let many Ubuntu clients update randon things at random times. How about central images that are maintained and tested by you and then rolled out; or in the other direction things like Ansible?
Completely independent of security, updates may break things. That's why.

deviantfan
  • 3,854
  • 21
  • 22
  • 4
    Whilst the anarchy of uncontrolled updates is indeed dangerous, the simplest (and probably most common) way to control updates is not to do them, which is also dangerous. – James_pic Aug 13 '17 at 22:36
  • 2
    This is fine for enterprises, but what about home users and small businesses? They're probably just using it as-is out of the box. Indeed, that's a selling point of Ubuntu (no elaborate configuration). If it's insecure in its default setup, should they be marketing this to individual users? – Kevin Aug 14 '17 at 05:11
  • @Kevin Well, "should" ... often, convenience is the opposite of security. And sadly, that's enough reason for security being a bother to many managers and other employees. If Ubuntu says "we won't ever let you enter a password in a GUI, not even XTerm, you always need to open a root terminal to do such things", that's not something that will help them with their market share. – deviantfan Aug 14 '17 at 06:03
  • 3
    And, anyways, a "secure" OS won't be possible as long as we don't know what to protect against, and how high the risks are. Ubuntu can't make this choice for "all" users, just for a reasonably sized part of it. (And that part has no idea what a terminal is). – deviantfan Aug 14 '17 at 06:06
  • 1
    @deviantfan And that part is also the more susceptible to sudo spoofs. Windows only have today's number of malwares because of its market share. As Ubuntu grows its slice, it becomes a more interesting target for malware, and the current incarnation of the OS can't defend end-users from smart attackers. This is a very major design failure. – T. Sar Aug 16 '17 at 10:51
  • 1
    @T.Sar Well, yes, but what's the solution then, that fits all target groups? Requiring terminals is not ok for non-technical users without skilled admin (=most users). Securing that dialog isn't really possible as long as X exists (and Wayland isn't that finished yet) – deviantfan Aug 16 '17 at 10:57
  • 1
    @deviantfan I'm not saying that you should fit all the target groups, just that for Ubuntu's biggest userbase (end users that have no idea how to use the Terminal), the current implementation is terrible. That, coupled with the false sense of security generated by years of "Linux-based systems can't be infected by viruses" propaganda is creating a very unsafe environment for the average user. Ubuntu, as is, is _dangerous_. Until Ubuntu finds a way to shield the lay user from this type of silly attack, I wouldn't recommend it for anyone. – T. Sar Aug 16 '17 at 11:27
  • 1
    @deviantfan You don't need to replace X completely - you could do the same thing as UAC - when you need to show the prompt, switch into a completely separate privileged application in a separate terminal session that just appears to be showing the old GUI. This is vastly simpler than replacing X. Not quite as strong as UAC, but a lot stronger than what they have now, and you can avoid having to enter the password (so no fake dialogs). If you're wondering about remote sessions, those are vulnerable (to key-loggers on the client side) on Windows too - just like running the system in a VM. – Luaan Aug 17 '17 at 07:58
  • @Luaan Nice idea, I'm just not sure if mixing sessions that much really is easier than replacing X... – deviantfan Aug 17 '17 at 18:06
22

Yes. This is insecure!

I personally always Cancel that dialog. Not because it could be fake, but because it could be real.

I am supposed to give escalated privileges to "an application" just because it asks? No, I don't think so.

System updates are fine, I do those manually, but it annoys me that the error reporting system requires this. Bad design.

Stig Hemmer
  • 2,403
  • 10
  • 14
  • Well, the *dialog* is not particularly insecure. That programs can on their own *ask to be elevated* is a risk (it would be the same risk on the command line). As so often, it's a matter of convenience. If you don't want to run programs which need root privs as root automatically right away (connect to your WLAN, upgrade your installation etc.) you would have to open a root shell or run sudo for that (which you apparently do with your upgrade). Not a bad idea but considered too cumbersome for a GUI oriented OS. – Peter - Reinstate Monica Aug 14 '17 at 14:39
  • 6
    The problem is that programs that need root privs aren't suid already. This is why suid exists. (Note: Do **NOT** suid the entire big graphical program. Make a small suid program that does the needed operation and nothing more) – Stig Hemmer Aug 15 '17 at 07:18
  • 2
    You are clearly not a fan of Ubuntu or of GUIs, are you? – oldmud0 Aug 17 '17 at 15:09
  • I am in general a fan of Ubuntu, but think they dropped the ball on this one. – Stig Hemmer Aug 21 '17 at 10:41
  • 1
    @oldmud0 Don't you remember when Vista came out and literally tens of millions of people complained about needing to click "Ok" on a UAC dialog constantly? The complaint becomes even worst in Ubuntu when you actually need to type the password in each time. Some things baffle me when they ask for escalation permissions.....like installing software from the Software Centre that only the current user will ever use (perhaps this has changed). I think Stig makes a point. Too many things ask for privilege escalation. – Lan Aug 22 '17 at 00:34
11

Contrary to what you feel, the (modern) Windows and Ubuntu ways of handling privilege levels and privilege elevation are fairly similar. The reason is surely that the operating systems are both multi-user systems with similar use cases which face similar problems.

Both operating systems restrict what an ordinary user can do (by running programs, of course). A user can destroy their own data but ideally not other people's (unless they shared it), and ideally cannot compromise or damage the system. In order to read and write system data a program needs administrator (root) privileges on both operating systems, which ordinarily only programs started by the admin/root have.

In order to make that simple, both operating systems provide the default user with the ability to run single programs with "elevated privileges" through sudo respectively UAC. Both operating system GUIs fire up a dialog in order to give the user a chance to prevent programs from running as administrator/root. Both systems also have the notion of users who are not allowed to run privileged programs at all.

The Ubuntu dialog asks for a password; the Windows UAC dialog doesn't. (You seem to think that a program needs special permissions to show that dialog; that is not the case. The program is asking for them with the dialog. If someone fakes the dialog they get your (user) password which is no gain for a program running already as that user.)

The bottom line of all this is that a malicious program can pretend that it needs elevated privileges for something useful and fire up the dialog, but once it has obtained them, format the hard drive.1 That is true for both operating systems. Because under Windows typically more third party software gets installed the chance to hit such a program is probably higher than for Ubuntu.

You mention that in Windows the UAC dialog usually is the result of a user action, for example installing a program, while Ubuntu fires the dialog up without apparent reason. One reason I can think of is that Windows software updates are initiated by the OS so that they have elevated privileges already. Maybe Ubuntu asks before installing.

It would indeed be nice to have more information than just "I need you passport, your boots and your jacket." I have no Ubuntu system at hand here, but I see a "Details" caption on the left side of the dialog. Did you look what is says? (Of course a malicious program could fake any text there, but you may be able to check whether the alleged program is indeed running.)


1Which would not be that terrible, compared to actually overwriting data.
  • 5
    Well, the Windows UAC stuff has some extra protection that makes spoofing harder, see https://blogs.msdn.microsoft.com/uac/2006/05/03/user-account-control-prompts-on-the-secure-desktop/ so on Ubuntu it is much easier for a rogue program to fake the dialog. – schlenk Aug 14 '17 at 12:59
  • @schlenk You are right; the integration of the GUI in the OS provides MS Windows with the authority to require a mandatory UAC dialog before privilege elevation. I wonder how Windows servers whose console may not be occupied handle that. Probably all programs which would need elevation at some point run as admin right away. But the basic problem seems to be that Linux prompts "out of the blue" while Windows' UAC prompt is (almost?) always the result of a user interaction (starting a program etc.). The main security advantage of the UAC prompt is that it cannot display wrong information. – Peter - Reinstate Monica Aug 14 '17 at 14:50
  • 1
    @PeterA.Schneider You get the Windows UAC prompt when connected over RDP, just the same as if you were at the console. I don't know if it's significantly different under the hood, but I suspect it isn't very much so. – user Aug 14 '17 at 15:11
  • You need to inform a password for UAC If you aren't logged in as admin or if you set UAC to always ask for it – T. Sar Aug 15 '17 at 16:31
  • The only time I'm aware of where the Windows' UAC prompt appears out of the blue is when a program that starts on startup requires admin privileges. Usually they only appear within the first 10 minutes (on an HDD) or 2-5 minutes (on an SSD) of startup. – Clonkex Aug 16 '17 at 03:59
  • @T.Sar Yes, but there's a good reason it isn't the default - it's actually less secure. It makes you vulnerable to fake UAC prompts that ask for your admin password (which cannot be prevented by the system). Just knowing the password doesn't allow you to elevate yourself without the UAC prompt either, but it can cause you some trouble. If you're admin, no point in asking for the password; if you're not, it's assumed the actual admin will be careful enough to prevent that (and ~99% of the time the admin is going to cancel anyway - think corporate). – Luaan Aug 17 '17 at 08:03
  • On Windows, privileged applications can launch other privileged applications without prompting - so update services are usually installed as privileged and no elevation is required. If they're well behaved, they *only* handle the installation and authorise the binaries properly, so it's a net security gain. Many programs aren't well-behaved, but it's getting better - it's starting to be that only installations and actually dangerous functions require elevation. As for the GUI, you *can* add a custom subsystem - but you're right that it isn't a 100% user-mode application, unlike X. – Luaan Aug 17 '17 at 08:10
5

The most secure way to make sure your password isn't been snooped is to use the SAK sequence: alt-sysrq-k. This will kill all programs on the current VT (including X11) and init will give you a fresh login prompt. The only attacks I'm aware of involve either changing the kernel keymap or compromising init itself, both of which require root-or-better access already.

There are various slightly-less-complete ways (XTerm has way to access X11's "exclusive input" option), depending on how much of your system you trust, but ... why shouldn't you be able to trust your system?

The major difference between the Linux and Windows security models is that under Linux, you don't just download random executables from the Internet and run them. (There are some efforts to package untrusted Linux applications in an Android-like package sandbox, but nobody uses them.)

o11c
  • 151
  • 2
  • 2
    I wouldn't call that a 'safety mechanism' implemented 'in Linux'... It's more of a workaround. – MiaoHatola Aug 14 '17 at 05:43
  • 2
    Magic SysRq support isn't guaranteed to be available. Like much else in the Linux kernel, it's a selectable option. – user Aug 14 '17 at 15:13
  • 2
    @MichaelKjörling and much like else in the Linux kernel, you probably haven't disabled it unless you know what you're doing. – o11c Aug 14 '17 at 16:18
  • 7
    @o11c: many distros disable most SysRQ functionality out of the box. For example, Ubuntu's `/etc/sysctl.d/10-magic-sysrq.conf` sets `kernel.sysrq = 176` = 128+32+16 = reBoot/powerOff, remount Ro, and Sync are the only commands enabled. See also https://askubuntu.com/questions/11002/alt-sysrq-reisub-doesnt-reboot-my-laptop. IDK why they disable SAK along with dumping Memory contents to the console (which they disable for security reasons). But apparently OpenSUSE uses 176, too. see also https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1025467: enable 176, was totally disabled before. – Peter Cordes Aug 14 '17 at 16:33
  • 2
    How is this an answer to the question? – GnP Aug 15 '17 at 21:41
-5

Horrible, horrible lack of security. When I saw the design of graphical sudo I bit the bullet and did sudo passwd root followed by apt-get remove sudo, then I really annoyed the ubuntu IRC folks by advocating uninstalling sudo.

Yet still the understand, this is utterly insecure. It was kinda ok on the terminal (more so when shells were weaker it was relatively unknown and attacks against it hadn't really developed) but is a glaring weakpoint now.

I will rather start a second X instance as root now for the less than once a year I have to give a graphical program root. (I do this by starting X :1 directly not by running startx so nothing but the target application is running in root's X instance). If you need root more often I advise apt-get install ssh and ssh -X root@localhost.

Joshua
  • 1,090
  • 7
  • 11
  • 10
    If you want reasons for downvotes ... a) uninstalling sudo won't help because this dialog is not sudo. b) This question is not about sudo being insecure, because it isn't. c) A second X instance won't help much. d) X as root? Not recommendable at all. e) ssh'ing the own local machine is not more secure than sudo, quite the opposite (more possibilities for code errors or wrong configs) – deviantfan Aug 15 '17 at 15:59
  • 1
    @deviantfan: The screen snapshot is clearly of a sudo prompt. X as root isn't insecure; it's the modern X environments that don't care. – Joshua Aug 15 '17 at 16:29
  • 8
    What you call a "sudo prompt" isn't run by the program sudo, and thus can't be removed by uninstalling sudo. Just try it, eg. by viewing the process list while the window is open. ... I don't know what the modernity of X environments has to do with anything. X, old and new, is built on principles that prevent secure password windows. It's not possible to change that without breaking X. – deviantfan Aug 15 '17 at 16:36
  • 1
    @deviantfan: Ctrl-Alt-Fx sequences to switch X environments and terminals works just fine. The myth that "X as root is insecure" comes from the myriad of modern window managers almost none of which are remotely hardened and so should not ever get root. There were a few safe ones in the old days. I kept ratpoison around until my eye problems got too bad to not have the accessibility support. – Joshua Aug 15 '17 at 16:40
  • a) Imho key combinations and rat poison are irrelevant here. b) I did not say that X as root is automatically insecure. c) Thank you for warning me from believing (in)security myths. Thankfully, I'm a natural sceptic anyways, and check many things myself before I believe them. d) I'm not discussing this further, there's no reason. – deviantfan Aug 15 '17 at 16:48
  • 4
    The prompt in question is from Polkit. Entirely different system. – muru Aug 16 '17 at 05:28