Isn't Ubuntu's system prompt for my password spoofable?

  • 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?

    Comments are not for extended discussion; this conversation has been moved to chat.

  • 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 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.

    I couldn't figure out how to fit this into the body, but mandatory xkcd

    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.

    While all of this is factually correct, I see little relationship to the question...

    Comments are not for extended discussion; this conversation has been moved to chat.

    _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?

    @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.

    "*I wouldn't be shocked if we start seeing Linux distros containerize web browsers and other high-risk applications in the coming years*" Qubes does this.

    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 I actually don't know enough about Wayland to talk about it. Feel free to suggest an edit though.

    @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 As usual, what counts as "secure" is in the eye of the beholder and relative to what you're trying to protect ;)

    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.

    @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.

    @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

    @SvenSlootweg Does that edit agree with your thoughts?

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM