Actions

Safely Use Root Commands

From Whonix



Root123123.jpg

Rationale[edit]

This wiki entry is intended to make attacks harder by denying root access: [1]

  • Prevent root compromise: these steps help to protect the virtualizer to avoid host compromise, and similarly the hardware to avoid hardware compromise. [2]
  • Protect against compromised non-root users: it is harder for any future, non-root users (such as www-data) to access user user or 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 user account. It is no longer necessary to have two secure passwords for the user user and root accounts. [3]

Default Passwords[edit]

Whonix / Kicksecure default admin password is: changeme default username: user
default password: changeme

The default root account is locked (or should be locked). [4] This is a purposeful security feature -- see below for further details.

General Security Advice[edit]

Commands that require root permissions should be run individually using sudo. In all cases:

  • Do not login as root.
  • Do not run sudo su.

Graphical Applications with Root Rights[edit]

It is discouraged to run graphical user interface (GUI) [archive] applications with sudo application:

  • Never login as root as explained above.
  • That is, never use sudo su and then start GUI applications.

This will fail and is a limitation inherited from Debian. If this action is attempted, error messages like those below will appear. [5]

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.

Open file /etc/default/keyboard in an editor with root rights.

(Qubes-Whonix ™: In TemplateVM)

This box uses sudoedit for better security [archive]. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/default/keyboard

Root Account[edit]

Enable Root Account[edit]

For security reasons the root account is locked and expired by default in Whonix ™ 15.0.0.3.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.

If you cannot use sudo:

Unexpire the root account.

sudo chage --expiredate -1 root

Set a root password.

sudo passwd

Disable Root Account[edit]

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

[6]

In the future, use sudo instead when it is necessary.

Unlock User Account: Excessive Wrong Password Entry Attempts[edit]

1. Launch a root terminal.

2. Run the following command.

sudo pam_tally2 -u user -r --quiet

Console Unlock[edit]

1. Launch a root terminal.

2. Run the following command. Replace user with the linux user account name which should be allowed to login on the console.

sudo addgroup user console

Advanced Users[edit]

Prevent Malware from Sniffing the Root Password[edit]

Any graphical application can see what is typed in another graphical application, for any user. [7] [8] 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:

  1. These instructions are ideally applied after installing the host / VM when it is still considered free of Malware.
  2. Create a new user account admin.
  3. Add it to the group sudo.
  4. Login as user admin.
  5. Remove user user from group sudo.
  6. 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).

1. Create a new user account admin.

sudo adduser admin

2. Add user admin to group sudo.

sudo addgroup admin sudo

Perform the following steps securely using sudo. Use one of the methods below.

Non-GUI Environment Method[edit]

This method is preferable until the limitation in the next section is documented.

1. Make sure keyboard gets disconnected from X Window System. (unraw) [9]

SysRq + r

2. Login as user admin from a non-graphical environment (virtual console). [10]

3. Perform any necessary administrative tasks.

4. Remove user user from group sudo.

Note: This only needs to be performed once.

sudo delgroup user sudo

5. Logout user admin and continue usual work as user user.

Logout Method[edit]

1. Login as user admin.

2. Logout user user first, then login as user admin.

Ensure that user user was really logged out and this process was not just simulated. TODO: research and document this procedure. SysRq + r?

3. Perform any necessary administrative tasks.

4. Remove user user from group sudo.

Note: This step only needs to be performed once.

sudo delgroup user sudo

5. Logout user admin and continue usual work as user user.

Substitute User (su) Command[edit]

The majority of users do not need to utilize the su command. [11].

Group sudo membership is required to use su [archive] (by package security-misc [archive]).

To permit the su command from user user, complete the following steps.

(Qubes-Whonix ™: perform these steps in Whonix-Gateway ™ and Whonix-Workstation ™ TemplateVMs.)

1. Enable the root account.
2. Add user user to group root.

sudo adduser user root

3. Re-enable SUID.

Set suid. Note it is okay if the second command fails.

sudo chmod 4755 /bin/su
sudo chmod 4755 /usr/bin/su

4. Add SUID whitelisting. [12]

sudo mkdir -p /etc/permission-hardening.d

Open file /etc/permission-hardening.d/20_user.conf in an editor with root rights.

(Qubes-Whonix ™: In TemplateVM)

This box uses sudoedit for better security [archive]. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/permission-hardening.d/20_user.conf

Add.

/bin/su exactwhitelist
/usr/bin/su exactwhitelist

Save.

Root Login[edit]

Root login within a virtual console will be disabled by default after upgrades. [13] [14]

To enable login from a virtual console, first apply the Enable Root Account instructions further above, then complete the steps below.

1. To allow root login, /etc/securetty must be configured. [15]

Open file $(realpath /etc/securetty) in an editor with root rights.

(Qubes-Whonix ™: In TemplateVM)

This box uses sudoedit for better security [archive]. This is an example and other tools could also achieve the same goal. If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit $(realpath /etc/securetty)

2. Add the following content.

Note: Add one or more tty depending on your circumstances; see file /etc/securetty.security-misc-orig.

tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10

hvc0

3. Save the file.

Recovery Mode[edit]

Root login is possible using recovery mode. [16]

When the root account is disabled, passwordless root login using recovery mode is possible; see below for the security impact.

Qubes Root Console[edit]

1. Open a dom0 terminal.

Qubes App Launcher (blue/grey "Q")System ToolsXfce Terminal

2. Run the following command.

Replace vm-name with the name of the actual VM where you want to open a root console.

qvm-run -u root vm-name xfce4-terminal

Passwordless Recovery Mode Security Discussion[edit]

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. [17]

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.

Development[edit]

Footnotes[edit]

  1. Also see: Permissions.
  2. https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132 [archive]
  3. On the flip-side, if the Prevent Malware from Sniffing the Root Password steps are followed, two secure passwords are required for the user user and user admin accounts.
  4. In new builds of Whonix version 15.0.0.3.6. Earlier Whonix builds did not lock the root account by default and should be locked.
  5. 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

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

  7. 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.
  8. 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.
  9. A GUI non-root user cannot sniff key strokes of different (non-)root users utilizing a virtual console.
  10. su is 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.

    By comparison, sudo makes it possible to execute system commands without the root password.

  11. This command will be unnecessary once /etc/permission-hardening.d has been deployed everywhere.
  12. security-misc /etc/securetty [archive] is empty by default.
  13. When trying to login as root in a virtual console it will reply:

    Login incorrect.

    Without previously asking for a password. This is not the worst case for usability and is better than asking for password and then failing.
  14. sudoedit will not follow symlinks, therefore realpath is used.
  15. https://forums.whonix.org/t/restrict-root-access/7658/46 [archive]


Search engines: YaCy | Qwant | ecosia | MetaGer | peekier


Follow: Twitter.png Facebook.png 1280px-Gab text logo.svg.png Iconfinder news 18421.png Rss.png Matrix logo.svg.png 1024px-Telegram 2019 Logo.svg.png Discourse logo.svg Reddit.jpg Diaspora.png Gnusocial.png Mewe.png 500px-Tumblr Wordmark.svg.png Iconfinder youtube 317714.png 200px-Minds logo.svg.png 200px-Mastodon Logotype (Simple).svg.png 200px-LinkedIn Logo 2013.svg.png

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

Whonix donate bitcoin.png Monero donate whonix.png United Federation of Planets 1000px.png

Share: Twitter | Facebook

Want to make Whonix safer and more usable? We're looking for helping hands. Check out the Open Issues [archive] and development forum [archive].

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. Policy of Whonix Website and Whonix Chat 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?)

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, Contact.