Safely Use Root Commands
- 1 Rationale
- 2 Default Passwords
- 3 General Security Advice
- 4 Graphical Applications with Root Rights
- 5 Root Account
- 6 Unlock User Account: Excessive Wrong Password Entry Attempts
- 7 Console Unlock
- 8 Advanced Users
- 9 Development
- 10 Footnotes
This wiki entry is intended to make attacks harder by denying root access: 
- Prevent root compromise: these steps help to protect the virtualizer to avoid host compromise, and similarly the hardware to avoid hardware compromise. 
- Protect against compromised non-root users: it is harder for any future, non-root users (such as
www-data) to access user
useror other parts of the system.
- Usability: if the advanced advice to Prevent Malware from Sniffing the Root Password is not followed, then users will only require a single, secure root password for the user
useraccount. It is no longer necessary to have two secure passwords for the user
userand root accounts. 
The default root account is locked (or should be locked).  This is a purposeful security feature -- see below for further details.
General Security Advice
Commands that require root permissions should be run individually using
sudo. In all cases:
- Do not login as root.
- Do not run
Graphical Applications with Root Rights
It is discouraged running GUI (graphical user interface) applications using
- Never login as
rootas explained above.
- I.e. never use
sudo suand then start GUI applications.
This will fail and is a limitation inherited from Debian. If a user attempts this action, error messages like those below will appear. 
No protocol specified
cannot connect to X server :0
As an XFCE user (Non-Qubes-Whonix default) use
lxsudo. For example.
/etc/default/keyboard in an editor with root rights.
(Qubes-Whonix ™: In TemplateVM)
Enable Root Account
For security reasons the root account is locked and expired by default in Whonix ™
126.96.36.199.6 and above. For most users there should be no need to use the root account. If it must be enabled for some reason, run the following commands.
(Qubes-Whonix ™: Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs)
Unexpire the root account.
sudo chage --expiredate -1 root
Set a root password.
Disable Root Account
The current Whonix ™ stable release and earlier versions come with the root account by default. Most users should disable it by running the following commands (Qubes-Whonix ™: Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs).
Lock the account.
sudo passwd --lock root
In the future, use
sudo instead when it is necessary.
Unlock User Account: Excessive Wrong Password Entry Attempts
1. Boot into recovery mode.
2. Run the following command.
sudo pam_tally2 -u user -r --quiet
1. Boot into recovery mode.
2. Run the following command.
sudo addgroup user console
Prevent Malware from Sniffing the Root Password
Any graphical application can see what is typed in another graphical application, for any user.   Therefore it is safer to create a special, new user account that is less likely to have been compromised, since this reduces the chances of malware sniffing the password to gain root access.
To more securely perform administrative tasks that require root access:
- These instructions are ideally applied after installing the host / VM when it is still considered free of Malware.
- Create a new user account
- Add it to the group
- Login as user
- Remove user
- Only then perform administrative tasks according to the instructions below.
This setup only needs to be completed once (Qubes-Whonix ™: Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs).
Perform the following steps securely using
sudo. Use one of the methods below.
Non-GUI Environment Method
This method is preferable until the limitation in the next section is documented.
Substitute User (su) Command
The majority of users do not need to use the
su command .
To be able to run
su from user
user, it is necessary to:
(Qubes-Whonix ™: perform these steps in Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs.)
- Enable the root account.
- Add user
sudo adduser user root
When the root account is disabled, passwordless root login using recovery mode is possible; see below for the security impact.
Passwordless Recovery Mode Security Discussion
This is only relevant on the host and not inside virtual machines.
Passwordless recovery mode is allowed because a locked root password would break the rescue and emergency shell. Therefore the security-misc [archive] package enables a passwordless rescue and emergency shell. This is the same solution that Debian will likely adapt for Debian installer. 
With passwordless root login, using recovery mode is allowed (through use of the security-misc package) on the host. To prevent adverse security effects posed by lesser adversaries with physical access to the machine, set up BIOS password protection, bootloader grub password protection and/or full disk encryption.
- Also see: Permissions.
- https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 [archive]
- On the flip-side, if the Prevent Malware from Sniffing the Root Password steps are followed, two secure passwords are required for the user
In new builds of Whonix version
188.8.131.52.6. Earlier Whonix builds did not lock the root account by default and should be locked.
No longer expiring the root account since this broke adduser, see: https://forums.whonix.org/t/restrict-root-access/7658/59 [archive]
(To prevent SSH login, see: Linux Locking An Account [archive]. This might prevent other login methods but this requires further investigation.)
sudo chage --expiredate 0 root
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.
- If an application is compromised with an exploit due to a security vulnerability, it can be used as malware by the attacker. Once/if the application is not effectively confined by a mandatory access control (MAC) framework like AppArmor or firejail, it can compromise the user account where it is running and then proceed from there.
- Broken X Window System can block switching to virtual console. If X Window System is capable of that it logically follows that also malware that compromised X Window System could do that. "SysRq + r" can take away control from X Window System. After that, switching to another virtual console is possible.
- A GUI non-root user cannot sniff key strokes of different (non-)root users utilizing a virtual console.
suis sometimes incorrectly referred to as the superuser command. It allows [archive]:
... a change to a login session's owner (i.e., the user who originally created that session by logging on to the system) without the owner having to first log out of that session.
Although su can be used to change the ownership of a session to any user, it is most commonly employed to change the ownership from an ordinary user to the root (i.e., administrative) user, thereby providing access to all parts of and all commands on the computer or system.
sudomakes it possible to execute system commands without the root password.
/etc/securetty [archive]is empty by default.
- When trying to login as root in a virtual console it will reply:
Without previously asking for a password. This is not the worst case for usability and is better than asking for password and then failing.
- https://forums.whonix.org/t/restrict-root-access/7658/46 [archive]
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211 [archive]
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?)