- There is nothing wrong with Debian's default
/etc/securettyfile as long as using a secure root password. Well, perhaps except a lot of ancient / uncommon login consoles?
- A compromised user account user
usercould be infected with a keylogger which could read the
sudopassword and thereby acquire root access.
- In Debian's default a secure password for user
userand root leads to compromised non-root users (such as user
sdwdatein case sdwdate gets exploited) to requiring a local privileged escalation exploit in order to acquire root compromise. Root password bruteforcing is not possible.
- A secure password for root/user accounts must not necessarily follow the same rationale as explained on the Passwords page. Offline attacks against the password (parallelization, attempts only limited by RAM, disk, and CPU) are not possible. Only "online" attacks are possible. Similar to attempts of cracking a password of a user account on a website. Only x attempts every y time are possible. See also https://forums.whonix.org/t/how-strong-do-linux-user-account-passwords-have-to-be-when-using-full-disk-encryption-fde-too/7698/14 [archive]
- Kicksecure / Whonix (package security-misc [archive]) limit to 100 password entry attempts until password unlock procedure is required.
- 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, any user account can attempt to use
suto try to switch to the root user or any other user account. Any user account can try to bruteforce switching to another user account.
- By Debian default, users who are not members of the group
sudo. Therefore limited user accounts (for example user
sdwdate) cannot use
sudoto 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
- Any graphical application running under X Windows System (X11) can see what any user is typing in any other application for any user.  For example, if user
userrunning X11 would run
lxsudo -u limited-user some-applicationthat application if compromised could sniff anything that user
useris writing. Including but not limited to any
- Kicksecure / Whonix / security-misc [archive] does not restrict user freedom. All default settings can be undone. Everything is configurable and documented on page Root.
- https://forums.whonix.org/t/restrict-root-access/7658 [archive]
- https://forums.whonix.org/t/how-strong-do-linux-user-account-passwords-have-to-be-when-using-full-disk-encryption-fde-too/7698/8 [archive]
Bruteforcing Linux User Account Passwords
Bruteforcing into linux user accounts is already severely limited in Whonix ™ and Kicksecure ™.
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.
- When attempting to login in a virtual console as root, which is no longer possible by default since Whonix
22.214.171.124.6, this will fail. This does not count as a login attempt fortunately for our pam_tally2 implementation in security-misc.
- VirusForget: about problematic files such as ~/.bashrc and other folders which malware can use to fake or sudo prompt and/or to persist after boot
- multiple boot modes for better security: persistent + root | persistent + noroot | live + root | live + noroot [archive]
- walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode [archive]
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.
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?
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/hvc0and also pass an open FD to it to your shell. Then, you (
user, and that shell) will be able to interact with
/dev/hvc0and 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.
(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.
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?)