From Whonix

< Dev


  • There is nothing wrong with Debian's default /etc/securetty file as long as using a secure root password. Well, perhaps except a lot of ancient / uncommon login consoles?
  • A compromised user account user user could be infected with a keylogger which could read the sudo password and thereby acquire root access.
  • In Debian's default a secure password for user user and root leads to compromised non-root users (such as user sdwdate in case sdwdate gets exploited) to requiring a local privileged escalation exploit in order to acquire root compromise. Root password bruteforcing is not possible.
  • Only one user account with password and no root account login supported by default also means the user has only to remember and secure one rather than two strong passwords.
  • By Debian default, users who are not members of the group sudo cannot use sudo. Therefore limited user accounts (for example user sdwdate) cannot use sudo to attempt to crack other user account passwords to run under these users.
  • Therefore there should be no way for limited user accounts which are compromised by malware to change to other user accounts such as root or user user.
  • Any graphical application running under X Windows System (X11) can see what any user is typing in any other application for any user. [1] For example, if user user running X11 would run lxsudo -u limited-user some-application that application if compromised could sniff anything that user user is writing. Including but not limited to any sudo password prompts.

Forum discussions:

Bruteforcing Linux User Account Passwords[edit]

Console Lockdown

Bruteforcing into linux user accounts is already severely limited in Whonix ™ and Kicksecure ™.

Quote security-misc [archive]:

This also has good usability. [archive]

This seems to function really well.

To further increase resistance to linux user account burteforcing attempts, the current 100 maximum password entry attempts were reduced to 50. [archive]




  1. Quote [archive] Joanna Rutkowska, security researcher, founder and advisor (formerly architecture, security, and development) of Qubes OS:

    One application can sniff or inject keystrokes to another one, can take snapshots of the screen occupied by windows belonging to another one, etc.

  2. [archive] @Patrick

    Why “I” can do it but user “man” cannot? What makes “me” and user “man” different?

    On non-Qubes Debian I am always wondering if I can switch a virtual console using ctrl + alt + F1, why can user “man” not? And how’s that different in Qubes?

    @marmarek wrote:

    This is about where the process is started and what has connected as controlling terminal. It isn’t anything Qubes specific. A non-privileged process cannot inject characters into a separate session (lets forget about X11 breaking all this assumptions, as we are talking about non-X11 session), especially if it’s of a different user, similarly as it cannot write to files it doesn’t have write permission. to. You can think of it as a write access to /dev/tty* (or /dev/hvc0 in this case). When you login on /dev/hvc0, login process (running as root) will setup permission to /dev/hvc0 and also pass an open FD to it to your shell. Then, you (user, and that shell) will be able to interact with /dev/hvc0 and specifically run commands connected to it. If you don’t login there, login process will not set the permissions, so you won’t have access. > This does assume kernel enforced permissions are effective, but as we are talking here about in-VM account isolation only, it’s a reasonable assumption.

    marmarek [archive]

    (lets forget about X11 breaking all this assumptions



    While experimenting [archive] with module loading disabling, I experienced that broken X can block switching to virtual console [archive]. Needless to say (for other readers), if X can do, also malware could do. “SysRq + r” can take away control from X. After that, switching to another virtual console was possible.


    Yes, X (or other process with access to input device) can grab it for exclusive access, disabling Alt+Ctrl+F1 or similar combos. This still is independent of what is happening on other terminals. Especially, input devices grabbed in this mode are handled by X server (or other process that grabbed them). As long as X server doesn’t have access to other terminals, it still can’t influence them.

Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Rss.png Matrix logo.svg.png 1024px-Telegram 2019 Logo.svg.png Discourse logo.svg

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate whonix.png

Share: Twitter | Facebook

We are looking for maintainers and developers.

https link onion link

This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation.

Copyright (C) 2012 - 2019 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)

Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint.