Safely Use Root Commands
What is the point on a typical single user Linux desktop computer of separating privileged administrator account (called
root account) and limited user accounts (such as for example user
It is assumed that most desktop computer users are single user computers. I.e. computers being used by only one person. Rather it is assumed that most users are only using a single login user account which will be refereed to as user
If someone steals my laptop while I'm logged in, they can read my email, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission.
Most people will consider their home directory as more important than root dirs
Once a malicious program has access to my home folder, I dont care if it also has access to the admin content
This is true for most users using single user computers, using only one user account and no virtual machines. As a counter messure this is why this documentation recommends recommends compartmentalization. I.e. running different activities in different virtual machines or even on different hardware.
The rationale of prevention of root compromise has the following goals: 
- Protect the virtualizer: this is to make it less likely that malware running inside the virtual machine can break out to the host operating system.  (Applies only when using virtual machines.)
- Protect the host operating system: Malware breaking out of the virtualizer is a lot harder without root access. (Applies only when using virtual machines.)
- Protect the hardware: A compromised host operating system might result in malware infecting the hardware, i.e. to avoid a persistent hardware backdoor (such as in BIOS or other firmware) surviving even re-installation of the host operating system. In many cases, root access is required before hardware can be attacked. 
- Protect against compromised non-root users: it is harder for potentially compromised other, non-root users (such as
www-data) to access user
useror other parts of the system.
- Sandboxing: Sandboxing applications can prevent applications getting exploited by attackers  or limit the severity of the exploit since if sandboxing is successfully, malware will be trapped inside the sandbox. Sandboxing is a lot harder, less efficient or even impossible when applications are running as root. See also AppArmor, apparmor-profile-everything and sandbox-app-launcher.
Kicksecure ™ implements various security hardening to Enforce Strong Linux User Account Isolation.
Once proposal Multiple Boot Modes for Better Security (an Implementation of Untrusted Root) has been implemented there will be a strong guidance for users to better separate their limited (everyday use) account (
user) and administrative account (
admin). This would result in a robust Prevention of Malware Sniffing the Root Password.
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
Inappropriate Use of Root Rights
Do not think of root as a shortcut to fix issues.
Inappropriate Use of Root Rights:
- Can cause additional non-security related issues.  Related is also next chapter Graphical Applications with Root Rights.
- Security issue.
Graphical Applications with Root Rights
- Never login as
rootas explained above.
- This includes, never use
sudo suand then start GUI applications.
No protocol specified
cannot connect to X server :0
As an XFCE user (Non-Qubes-Whonix default) use
lxsudo instead. For example, to launch the keyboard GUI safely, run.
/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 ™
184.108.40.206.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)
If you can use
sudo, you can skip the following box.
Unexpire the root account.
sudo chage --expiredate -1 root
Set a root password.
Disable Root Account
Earlier versions of Whonix ™ (version numbers lower than
220.127.116.11.6) come with the root account enabled 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
The following steps can be used in case the user entered the wrong password too many times which resulted in the user account being automatically locked.
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.
This process is currently for advanced users only since it is quite cumbersome, i.e. has bad usability. The usability of this will be improved once proposal Multiple Boot Modes for Better Security (an Implementation of Untrusted Root) has been implemented.
To more securely perform administrative tasks that require root access:
- Prerequisite knowledge: how to switch to a different virtual console, usage of the SysRq key key and login spoofing.
- 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
- Advantage: can keep current user session(s) and/or graphical session (X Window System) running.
- Disadvantage: cannot use graphical session during administrative tasks. 
- Advantage: can use graphical session (X Window System) during administrative tasks using privileged user
- Disadvantage: cannot keep graphical session of unprivileged user
userrunning. In other words, simplified, all applications run under user
userwill be terminated. 
Substitute User (su) Command
The majority of users do not need to utilize the
su command. .
In Kicksecure ™ (and Whonix ™), by default:
sudomembership is required to use
useris a member of group
sudo. ([Dev/boot_modes|This might change in a later release.]])
When the root account is disabled, passwordless root login using recovery mode is possible; see below for the security impact.
Qubes Root Console
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.
dsudo - default password sudo
dsudo is a Whonix ™ and Kicksecure ™ specific feature.
As long as still using the default password (not having changed sudo password), commands can be run as root without entering a password. This is useful for users having issues with changing the keyboard layout and for testing VMs.
Instead of using
- Whonix code: Restrict access to the root account [archive].
- https://forums.whonix.org/t/sysrq-magic-sysrq-key/8079/68 [archive]
- https://forums.whonix.org/t/should-lesser-adversaries-with-physical-access-be-part-of-the-threat-model-of-whonix-whonix-host-kicksecure/7997 [archive]
- Also see: Permissions.
- https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 [archive]
- For example flash utilities for Linux require root access. In theory, it's conceivable of software bugs in firmware of hardware resulting in hardware compromise without prior root compromise. No such examples happening in the wild where known to the author at time of writing.
- An exploit or payload might require a function which is unavailable inside the sandbox.
In new builds of Whonix version
18.104.22.168.6. Earlier Whonix builds did not lock the root account by default and should be locked.
- Applications supposed to be run as user but run as root might create root owned files. These file permissions error can lead to additional issues.
- Inter process communications such as with dbus might be broken.
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.
- Unless perhaps advanced users manage to run a different X server on a different virtual console. This might not be possible, secure. Depends on if the exclusive lock of X can be suspended while using an X server in a different virtual console. This has not been researched.
- This step might be unnecessary. Not researched yet.
Alt + Crtl + F7results in
tty2. This is to make these instructions compatible with most Linux distributions as well as Qubes.
- Most Linux distributions login CLI virtual consoles on
Alt + Crtl + F1) by default and X Window System on
Alt + Crtl + F7).
- Qubes X Window System by default runs on
Alt + Crtl + F1)
Alt + Crtl + F2) will be most most users an unused virtual console which can be used for the purpose of this chapter.
- Most Linux distributions login CLI virtual consoles on
A X Window System non-root user cannot sniff key strokes of different (non-)root users utilizing a different virtual console (
Non-simplified: applications run by user
userin a different virtual console or run through systemd (user) services can be left running.
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.
- Implemented in package security-misc [archive].
sudo chmod 4755 /bin/su sudo chmod 4755 /usr/bin/su
/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.
sudoeditwill not follow symlinks, therefore
- 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. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2020 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?)