title=Safely Use Root Commands

{{Header}}
{{Title|
title=Safely Use Root Commands
}}
{{#seo:
|description=Tips on using sudo / root (privileged) commands safely
|image=User-versus-root.png
}}
{{passwords_mininav}}
[[File:User-versus-root.png|200px|thumb]]
{{intro|
This page gives tips on using <code>sudo</code> / <code>root</code> (privileged) commands safely. The <code>root</code> account is a special user account in Unix-based operating systems that has complete access to all files and commands on a system. It is typically used only for system administration tasks that require unrestricted access.
}}

= Introduction =

Learn why '<code>root</code>' is important, what it is used for, and how to use <code>sudo</code> / <code>root</code> (privileged) commands safely.

= Rationale for Protecting the Root Account =

{{Anchor|Rationale}}

What is the point on a typical single user Linux desktop computer of separating privileged administrator account (called <code>root</code> account) and limited user accounts (such as for example account <code>user</code>)?

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 referred to as account <code>user</code>.

Quote [https://xkcd.com/1200/ xkcd authorization]:

<blockquote>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.</blockquote>

[https://askubuntu.com/questions/16178/why-is-it-bad-to-log-in-as-root Quote] user discussion:

<blockquote>Most people will consider their home directory as more important than root dirs</blockquote>

<blockquote>Once a malicious program has access to my home folder, I don't care if it also has access to the admin content</blockquote>

This is true for most users using single user computers, using only one user account and no virtual machines. As a counter measure this is why this documentation [[Special:Search/compartmentalization|recommends compartmentalization]], that is, running different activities in different virtual machines or even on different hardware.

The rationale of prevention of <code>root</code> compromise has the following goals: <ref>
Also see: [[Dev/Strong_Linux_User_Account_Isolation|Permissions]].
</ref>

* Protect the host operating system: If using {{VMs}}: It is much less likely that malware will break out of a virtual machine if it does not have <code>root</code> access within the VM. <ref>
https://github.com/QubesOS/qubes-issues/issues/2695#issuecomment-301316132
</ref> This is because <code>root</code> can change kernel settings (to wide. attack surface), load kernel modules. This is also called VM escape.
* Protection from rootkits: Root access allow malware to install <code>rootkits</code>, which can be very difficult to detect and remove.
* Protect the virtualizer: It is harder to attack the virtualizer without <code>root</code> / kernel access. (Applies only when using virtual machines.)
* Protect the hardware: A compromised host operating system might result in malware infecting the hardware, i.e. [[malware]] could install a persistent [[Backdoor#Hardware_Backdoor|hardware backdoor]] (such as in BIOS or other [[Backdoor#Firmware_Trojan|firmware trojan]]) surviving even re-installation of the host operating system. In many cases, <code>root</code> access is required before hardware can be attacked. <ref>
For example flash utilities for Linux require <code>root</code> access. In theory, it's conceivable of software bugs in firmware or hardware resulting in hardware compromise without prior <code>root</code> compromise. No such examples happening in the wild were known to the author at time of writing.
</ref>
* Protect against compromised non-root users: it is harder for potentially compromised non-root users (such as <code>www-data</code>) to access account <code>user</code> or other parts of the system. This is important when considering that even single-user systems have many system-level user accounts.
* Sandboxing: Sandboxing applications can prevent applications getting exploited by attackers <ref>
An exploit or payload might require a function which is unavailable inside the sandbox.
</ref> 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 <code>root</code>. See also [[AppArmor]], [[apparmor.d|<code>apparmor.d</code> (Full System AppArmor Profile)]] and [[sandbox-app-launcher]].

{{project_name_short}} implements various security hardening to [[Dev/Strong_Linux_User_Account_Isolation|Enforce Strong Linux User Account Isolation]].

[[Dev/user-sysmaint-split|<code>user-sysmaint-split</code> (Multiple Boot Modes for Better Security)]] can provide strong guidance for users to better separate their limited (everyday use) account (<code>user</code>) from their administrative account (<code>sysmaint</code>). This results in robust [[root#Prevent Malware from Sniffing the <code>Root</code> Password|Prevention of Malware Sniffing the Root Password]].

= Default Passwords =

The default passwords for {{project_name_short}} are:

{{Default_Passwords}}

The default <code>root</code> account is locked (or should be locked). <ref>
In new builds of {{project_name_long}} version <code>15.0.0.3.6</code>. Earlier {{project_name_long}} builds did not lock the <code>root</code> account by default and should be locked.
</ref> This is a purposeful security feature -- see below for further details.

Users can [[Post_Install_Advice#Change_Passwords|change or set a password]] for security reasons if this is useful in their case based on this [[Default_Passwords#Information|Information]].

= Running with Root Access =

== Run with Administrative Rights ==
To run an application with administrative ("<code><nowiki>root</nowiki></code>") rights.

{{IconSet|h2|1}} {{sysmaint_notice}}

{{IconSet|h2|2}} '''Use a privilege elevation utility to run commands as <code>root</code>.'''

Note: Replace <code>command</code> with the actual command.

* {{cli}}: {{CodeSelect|inline=true|code=sudo command}}
* {{gui}}: See [[Root#Graphical_Applications_with_Root_Rights|Graphical Applications with <code>Root</code> Rights]].

{{IconSet|h2|3}} '''Password entry.'''

If a password has been [[Login#Configuring_Passwords|configured]], the utility will prompt for it.

{{IconSet|h2|4}} '''Done.'''

{{IconSet|h2|5}} '''Test command.'''

Run a test command with administrative ("<code>root</code>") rights.

This is only a simple test to confirm that the user can currently escalate to administrative rights. <ref>
This helps avoid mistakenly attributing issues to running a program with root rights, when the actual problem lies with <code>sudo</code> authentication.
</ref> Type the following command in the terminal and press <code><Enter></code>.

{{CodeSelect|code=
sudo whoami
}}

Expected output.

<pre>
root
</pre>

== User Password versus Root Password ==

Tools such as <code>sudo</code> and <code>lxsudo</code> prompt for the password of the <code>user</code> account. This is different from the <code>root</code> account password.

= Security and Best Practices =

== General Security Advice ==

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

* Do not login as <code>root</code>.
* Do not run <code>sudo su</code>.

== Inappropriate Use of Root Rights ==
Do not think of <code>root</code> as a shortcut to fix issues.

{{mbox
| image = [[File:Ambox_warning_pn.svg.png|40px]]
| text =
It is very much discouraged to establish the following behavior: 
<code>application problem</code> → "try <code>sudo</code> / <code>root</code>".

Only use privilege escalation tools such as <code>sudo</code>, <code>lxsudo</code> or the accounts <code>sysmaint</code> / <code>root</code> if there is a strong rationale for doing so. Otherwise...
}}

Inappropriate Use of <code>root</code> Rights:

* Can cause additional non-security related issues. <ref>
* Applications supposed to be run as user but run as <code>root</code> might create <code>root</code> owned files. These file permissions error can lead to additional issues.
* Inter process communications such as with dbus might be broken.
</ref> Related is also later chapter [[#Graphical Applications with Root Rights|Graphical Applications with <code>Root</code> Rights]].
* Risks harmful code being run as <code>root</code>.

= Graphical Applications and Root Rights =

{{Anchor|Graphical_Applications_with_Root_Rights}}

{{IconSet|h2|1}} '''Do not run {{gui}} with <code>sudo</code>!'''

It is discouraged to run [https://www.computerhope.com/jargon/g/gui.htm graphical user interface (GUI)] applications with <code>sudo gui-application</code>.

* Never login as <code>root</code> as explained above.
* This includes, never use <code>sudo su</code> and then start GUI applications.

Doing so would be an [[#Inappropriate Use of Root Rights|Inappropriate Use of <code>Root</code> Rights]]. That would fail in many cases and is a limitation inherited from Debian. If this action is attempted, error messages like those below will appear. <ref>
* https://help.ubuntu.com/community/RootSudo#Graphical_sudo
* https://www.psychocats.net/ubuntu/graphicalsudo
</ref>

<pre>
No protocol specified
</pre>

<pre>
cannot connect to X server :0
</pre>

{{IconSet|h2|2}} '''If there is a legitimate reason to start GUI applications with <code>root</code> rights when using X11, use <code>lxsudo</code> instead.''' <ref>
* Reason primarily: not breaking the system, reliability. Non-reason: security.
* https://askubuntu.com/questions/270006/why-should-users-never-use-normal-sudo-to-start-graphical-applications
* In past there was <code>gksudo</code>, <code>kdesudo</code>. Nowadays with more and more applications using PolicyKit or polkit, these applications are no longer available as of Debian <code>buster</code>. <code>lxsudo</code> is an alternative.
</ref> Syntax:

{{CodeSelect|code=
lxsudo application-name
}}

For example to start the partition manager <code>gparted</code> by default with <code>root</code> rights.

{{CodeSelect|code=
lxsudo gparted
}}

<ref>
<code>sudo</code> with <code>-H</code> / <code>--set-home</code> would also be OK. Syntax:
{{CodeSelect|code=
sudo -H application-name
}}

Or.

{{CodeSelect|code=
sudo --set-home application-name
}}

For example to start the partition manager <code>gparted</code> by default with <code>root</code> rights.

{{CodeSelect|code=
sudo -H gparted
}}

Or.

{{CodeSelect|code=
sudo --set-home gparted
}}
</ref>

'''If there is a legitimate reason to start GUI applications with <code>root</code> rights when using Wayland, see [[#Wayland|Wayland]] instructions below.'''

{{IconSet|h2|3}} '''To edit files which can only be edited with <code>root</code> rights. Use the following syntax.'''

Note: Replace <code>/path/to/file/name</code> with the actual path to the file.

{{Open with root rights|filename=
/path/to/file/name
}}

For example:

{{Open with root rights|filename=
/etc/default/keyboard
}}

== Polkit PolicyKit pkexec for GUI applications ==
{{Anchor|Polkit_PolicyKit_pkexec}}

Use of [https://en.wikipedia.org/wiki/Polkit Polkit] (formerly PolicyKit) (<code>pkexec</code>) might also be appropriate for running GUI applications with root rights. Usually such applications should have desktop shortcuts or wrappers which make use of <code>pkexec</code>. There are no (or rare) known cases where users need to run <code>pkexec</code> on the command line.

== Wayland ==

Running GUI applications as <code>root</code> (<code>lxsudo</code>, <code>sudo --set-home</code>, <code>pkexec</code> will be more difficult once {{project_name_long}} has been ported from X11 to Wayland. This is because Wayland requires applications to access <code>$XDG_RUNTIME_DIR/$WAYLAND_SOCKET</code> to open GUI windows. <ref>https://unix.stackexchange.com/a/423287/535873</ref> You may run into this when using [[Other Desktop Environments]] using Wayland.

The following command should work to run Wayland applications as <code>root</code> in most instances. Replace <code>application-name</code> as appropriate:

{{CodeSelect|code=
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR application-name
}}

Qt applications may try to use X11 by default, in which case this technique will fail. To override this and make Qt attempt to use Wayland instead, use:

{{CodeSelect|code=
sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR QT_QPA_PLATFORM=wayland application-name
}}

= Root Account Management =
{{Anchor|Root_Account}}

== Default Setting ==

* '''Root account locked:''' For [[#Rationale|security reasons]], the <code>root</code> account has been configured into the state of "locked" for [[login]] by default in {{project_name_short}}. <ref>
Since version <code>15.0.0.3.6</code> and above.
</ref>
* '''Definition complexity:''' The definition and repercussions of a "locked" Linux user account, however, are complicated for all Linux distributions. For technical details on what this means exactly, advanced users can refer to the wiki chapter [[Dev/Strong_Linux_User_Account_Isolation#Root_Account_Locked|<code>Root</code> Account Locked]] and [[User#Meanings_of_Special_Characters_in_the_Password_Field_of_.2Fetc.2Fshadow_File|Meanings of Special Characters in the Password Field of /etc/shadow File]].
* '''No <code>root</code> usage needed:''' Most users should not need to use the <code>root</code> account.

== Avoid Root Login ==

Should the user log in as <code>root</code>? No. See footnote for rationale. <ref>
{{anchor_link|avoid_root_login_details}}
Why not log in as <code>root</code>? This is due to historical and legacy reasons.

Even during the era of X11, <code>root</code> login was discouraged.

For strong user isolation, logging into the <code>root</code> account should be avoided.

In an ideal world, the extra <code>sysmaint</code> user would be unnecessary, and users could simply rely on the <code>root</code> account. Or better yet, all references to <code>root</code> would be removed and replaced with <code>sysmaint</code>. However, educating and convincing many upstream projects to adopt this approach for the purpose of [[Dev/Strong Linux User Account Isolation]] is unrealistic due to organizational constraints, which are elaborated on in the [[Linux User Experience versus Commercial Operating Systems]] page.
</ref>

{{sdebian
|link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1382
|text=Using su
}}

== Enable Root Account ==

If the user wants to enable the <code>root</code> account, run the following commands.

{{IconSet|h2|1}} {{sysmaint_notice}}

{{IconSet|h2|2}} '''Platform-specific notice.'''

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: No special notice.
* [[Qubes|{{q_project_name_short}}]]: Inside <code>{{project name workstation template}}</code> Template.

{{IconSet|h2|3}} '''Choose <code>sudo</code> availability.'''

{{Tab
|type=controller
|content=
{{Tab
|title= === sudo available ===
|type=section
|content=
If you can use <code>sudo</code>, follow the instructions below.
}}
{{Tab
|title= === sudo unavailable ===
|content=
If you cannot use <code>sudo</code>:

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: Boot into [[Recovery#Recovery_Mode|recovery mode]].
* [[Qubes|{{q_project_name_short}}]]: Open a [[#qubes_root_console|Qubes <code>Root</code> Console]].
}}
}}

{{IconSet|h2|4}} '''Set a <code><nowiki>root</nowiki></code> password.'''

See [[Login#Configuring_Passwords|configuring passwords]] for detailed information on changing user account passwords.

Note: These instructions apply to the <code>user</code> account. Replace <code>user</code> with <code>root</code>. <ref>
Unexpire the <code>root</code> account.

{{CodeSelect|code=
sudo chage --expiredate -1 root
}}
</ref>

{{IconSet|h2|5}} '''Done.'''

The <code>root</code> account has been unlocked.

== Disable Root Account ==
'''Applicability:'''

* '''[[Old Stable and Earlier Releases|Earlier versions]]:''' {{project_name_short}} (versions lower than <code>15.0.0.3.6</code>) came with the <code>root</code> account enabled by default.
* '''[[Distribution_Morphing|Distro-morphing]]:''' Users who installed [[Debian|Kicksecure inside Debian]] using the installation method described in the [[Debian#User_Account_Information|User Account Information]] section.

Most users should disable the <code>root</code> account by running the following commands.

{{IconSet|h2|1}} {{sysmaint_notice}}

{{IconSet|h2|2}} '''Platform-specific notice.'''

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: No special notice.
* [[Qubes|{{q_project_name_short}}]]: Inside <code>{{project name workstation template}}</code> Template.

{{IconSet|h2|3}} '''Lock the <code>root</code> account.'''

{{CodeSelect|code=
sudo passwd --lock root
}}

<ref>
The <code>root</code> account is no longer expired, as this previously broke the <code>adduser</code> command. See: https://forums.whonix.org/t/restrict-root-access/7658/59

{{CodeSelect|code=
sudo chage --expiredate 0 root
}}

To prevent SSH login, see [[SSH#SSH_Login_Comparison_Table|SSH Login Comparison Table]].
</ref>

{{IconSet|h2|4}} '''Done.'''

The <code>root</code> account has been locked.

In the future, [[#General Security Advice|use <code>sudo</code> instead]] when necessary.

= Troubleshooting =
== Permissions Fix ==

After [[#Inappropriate Use of Root Rights|inappropriate use of <code>root</code> rights]], attempt to fix:

{{Open a product ws terminal}}

Run the following command to reset permissions of account <code>user</code>'s home folder <code>/home/user</code> back to owner <code>user</code> and group <code>user</code>.

{{CodeSelect|code=
sudo chown --recursive user:user /home/user
}}

== Reset User Account Password ==
The following steps can be used in case the password has been forgotten and needs to be reset.

{{Box|text=
{{IconSet|h2|1}} '''Launch a <code>root</code> terminal.'''

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: Boot into [[Recovery#Recovery_Mode|recovery mode]].
* [[Qubes|{{q_project_name_short}}]]: Open a [[#qubes root console|Qubes <code>Root</code> Console]].

{{IconSet|h2|2}} '''Notes'''.

* This process will be similar to the [[Post_Install_Advice#Change_Password|change password]] wiki chapter which is recommended to read as it contains instructions / links on how to change and test the keyboard layout.
* This is [[unspecific|unspecific to {{project_name_short}}]]. It should be a very similar process on Debian or most other Linux distributions. It can also be resolved as per [[Self Support First Policy]].

{{IconSet|h2|3}} '''Set a new password.'''

To change the password for account <code>user</code>, run the following command.

{{CodeSelect|code=
sudo passwd user
}}

{{IconSet|h2|4}} '''Reboot.'''

{{CodeSelect|code=
sudo reboot
}}

{{IconSet|h2|5}} '''Done.'''

The process of password reset has been completed.
}}

== Unlock User Account: Excessive Wrong Password Entry Attempts ==
{{Anchor|unlock}}
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. (This is related to security feature [[Dev/Strong_Linux_User_Account_Isolation#Bruteforcing_Linux_User_Account_Passwords_Protection|Bruteforcing Linux User Account Passwords Protection]].)

{{Box|text=
{{IconSet|h2|1}} '''Launch a terminal that can run commands as <code>root</code>.'''

If you cannot login anymore, see the bullet points below:

Platform specific.

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: Boot into [[Recovery#Recovery_Mode|recovery mode]].
* [[{{q_project_name_short}}|{{q_project_name_short}}]]: Open a [[#qubes root console|Qubes <code>Root</code> Console]].

{{IconSet|h2|2}} '''Run the following command.''' <ref>
{{project_name_short}} configuration file [https://github.com/Kicksecure/security-misc/blob/master/etc/security/faillock.conf.security-misc <code>/etc/security/faillock</code>] by package [[security-misc]] sets:
<pre>
dir = /var/lib/security-misc/faillock
</pre>
It is therefore necessary to use the <code>faillock</code> command with the <code>--dir /var/lib/security-misc/faillock</code> option.
</ref>

Note: Replace <code>user</code> with the actual name of the user that you wish to unlock.

{{CodeSelect|code=
sudo faillock --dir /var/lib/security-misc/faillock --user user --reset
}}

{{IconSet|h2|3}} '''Done.'''

Unlocking of user account has been completed.
}}
{{Anchor|console}}

== Console Unlock ==

{{Box|text=
{{IconSet|h2|1}} '''Launch a <code>root</code> terminal.'''

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]: Boot into [[Recovery#Recovery_Mode|recovery mode]].
* [[Qubes|{{q_project_name_short}}]]: Open a [[#qubes root console|Qubes <code>Root</code> Console]].

{{IconSet|h2|2}} '''Learn the syntax.'''

Note: Do not run this command. Only for reference, explanation.

<pre>
sudo adduser account-name group-name
</pre>

{{IconSet|h2|3}} Add the account to group Linux user group <code>console</code>.

Run the following command.

Note: Replace <code>user</code> with the Linux user account name which should be allowed to login on the [[login]] console.

{{CodeSelect|code=
sudo adduser user console
}}

{{IconSet|h2|4}} '''Done.'''

The account has been added to group <code>console</code>.
}}

= Advanced Users =
== Prevent Malware from Sniffing the Root Password ==
=== Rationale for Separate sysmaint Account ===
{{anchor|Rationale for Separate admin Account}}

If Linux user account <code>user</code> is compromised and has <code>sudo</code> access, malware can easily steal the administrative ("<code>sudo</code>") password. <ref>
Any graphical application can see what is typed in another graphical application, for any account.

[https://blog.invisiblethings.org/2011/04/23/linux-security-circus-on-gui-isolation.html Quote] Joanna Rutkowska, security researcher, founder and advisor (formerly architecture, security, and development) of Qubes OS:

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

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.

See also [[Dev/Strong_Linux_User_Account_Isolation#sudo_password_sniffing|sudo password sniffing]] for technical details.
</ref> Therefore it is more secure ([[#Rationale|rationale]]) to perform administrative actions such as running <code>sudo</code> from a separate [[sysmaint|<code>sysmaint</code> (System Maintenance) account]] that is less likely to get compromised, since this reduces the chances of malware sniffing the password to escalate to administrative ("<code>root</code>") access.

The basic concept is a separation of the following accounts:

* '''account <code>user</code>:''' Perform everyday actions such as running web browsers.
* '''account <code>sysmaint</code>:''' Perform system maintenance administrative actions such as installing additional packages.

Questions and answers:

* Is running applications such as browser under account <code>sysmaint</code> less secure? Yes, that defeats this concept.
* Is running applications such as browser under account <code>user</code> more secure? Yes, because it becomes harder for malware to perform privilege escalation attacks to gain administrative ("<code>root</code>") access.
* What is so bad about malware escalating to administrative? See [[#Rationale|rationale]].
* Why use account <code>sysmaint</code> and not simply the <code>root</code> account? See [[Root#Avoid_Root_Login|Avoid <code>Root</code> Login]].

=== Overview of Steps ===
To more securely perform administrative tasks that require <code>root</code> access, see the following overview steps below. Detailed technical steps are available further below.

# Prerequisite knowledge: [[Login spoofing|login spoofing]]
# These instructions are ideally applied after installing the host / VM when it is still considered free of [[Malware and Firmware Trojans|malware]].
# Only then perform administrative tasks according to the instructions below.

=== Detailed Steps ===

{{IconSet|h2|1}} '''Check if <code>user-sysmaint-split</code> is already installed.'''

See [[Sysmaint#Default_Installation_Status|sysmaint Default Installation Status]].

{{IconSet|h2|2}} '''Install the <code>user-sysmaint-split</code> package, if needed.'''

This is required to create user <code>sysmaint</code>. For instructions, see [[Sysmaint#Installation|<code>user-sysmaint-split</code> Installation]].

{{IconSet|h2|3}} '''Perform the following steps securely using <code>sudo</code>. Use one of the methods below.'''

{{Tab
|type=controller
|content=

{{Tab
|title= ===Power-off and Power-on Cycle Method===
|type=section
|content=

* Advantages:
** Recommended.
** Most secure method.
* Disadvantage:
** Cannot keep graphical session of unprivileged account <code>user</code> running. In other words, simplified, all applications run under account <code>user</code> will be terminated.

{{IconSet|h3|1}} Power off.

Shutdown the system. Really power off. Not shutdown. Why? To defeat [[login spoofing]].

{{IconSet|h3|2}} Power on.

{{IconSet|h3|3}} See [[Sysmaint#Usage|Usage]].

{{IconSet|h3|4}} Perform any necessary administrative tasks.

{{IconSet|h3|5}} Power off.

{{IconSet|h3|6}} Power on.

{{IconSet|h3|7}} Done.
}}

{{Tab
|title= ===Non-GUI Environment Method===
|type=section
|content=

* Advantage: can keep current account session(s) and/or graphical session (X Window System) running.
* Disadvantages:
** [[Unsupported]]. Less secure. ([[Dev/user-sysmaint-split#Fast_User_Switching|<code>user-sysmaint-split</code> (developers), Fast User Switching]])
** Cannot use graphical session during administrative tasks <ref>
Unless perhaps advanced users manage to run a different X server on a different virtual console. This might not be possible or 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.
</ref>
** Requires [[SysRq]], which is [[SysRq#Kicksecure_Default_SysRq_Configuration|disabled by default in Kicksecure for security reasons]].

{{IconSet|h3|1}} [[SysRq#Enable_SysRq|Enable SysRq]].

{{IconSet|h3|2}} Make sure keyboard gets disconnected from X Window System to [[Login spoofing|defeat login spoofing]]. (<code>unraw</code>) <ref name=unraw-required-questionmark>
This step might be unnecessary. Not researched yet.
</ref>

[[SysRq]] + <code>w</code>

(Press <code>Alt + SysRq + w</code>)

{{IconSet|h3|3}} Switch to another [[Desktop#Virtual_Consoles|virtual console]].

(Press <code>Alt + Crtl + F2</code>) <ref>
Pressing <code>Alt + Crtl + F7</code> results in <code>tty2</code>.

This is to make these instructions compatible with most Linux distributions as well as Qubes.

* Most Linux distributions login CLI virtual consoles on <code>tty1</code> (<code>Alt + Crtl + F1</code>) by default and X Window System on <code>tty7</code> (<code>Alt + Crtl + F7</code>).
* Qubes X Window System by default runs on <code>tty1</code>. (<code>Alt + Crtl + F1</code>)

<code>tty2</code> (<code>Alt + Crtl + F2</code>) will be for most users an unused virtual console which can be used for the purpose of this chapter.
</ref>

{{IconSet|h3|4}} Press Secure Access Key also to [[Login spoofing|defeat login spoofing]].

[[SysRq]] + <code>k</code>

(Press <code>Alt + SysRq + k</code>)

{{IconSet|h3|5}} Login as account <code>sysmaint</code> from that non-graphical environment ([[Desktop#Virtual_Consoles|virtual console]]). <ref>
An X Window System non-<code>root</code> account cannot sniff keystrokes of different (non-)<code>root</code> users utilizing a different virtual console (<code>tty</code>).
</ref>

{{IconSet|h3|6}} Perform any necessary administrative tasks.

{{IconSet|h3|7}} Logout account <code>sysmaint</code>.

{{CodeSelect|code=
logout
}}

{{IconSet|h3|8}} Switch back to previous virtual console.

X Window System runs in:

* most Linux distributions: virtual console <code>7</code> (Press <code>Alt + Crtl + F7</code>)
* Qubes: virtual console <code>1</code> (Press <code>Alt + Crtl + F1</code>)

{{IconSet|h3|9}} Re-login if needed and continue usual work as account <code>user</code>.

{{IconSet|h3|10}} Done.
}}

{{Tab
|title= ===Logout Method===
|type=section
|content=

* Advantage:
** Can use graphical session (X Window System) during administrative tasks using privileged account <code>sysmaint</code>.
* Disadvantages:
** [[Unsupported]]. Less secure. ([[Dev/user-sysmaint-split#Fast_User_Switching|<code>user-sysmaint-split</code> (developers), Fast User Switching]])
** Cannot keep graphical session of unprivileged account <code>user</code> running. In other words, simplified, all applications run under account <code>user</code> will be terminated. <ref>
Non-simplified: applications run by account <code>user</code> in a different virtual console or run through systemd (<code>--system</code> or <code>--user</code>) services can be left running.
</ref>
** Requires [[SysRq]], which is [[SysRq#Kicksecure_Default_SysRq_Configuration|disabled by default in Kicksecure for security reasons]].

{{IconSet|h3|1}} [[SysRq#Enable_SysRq|Enable SysRq]].

{{IconSet|h3|2}} Terminate all running applications in current graphical (X) session.

{{IconSet|h3|3}} Log out.

<code>Start Menu</code> -> <code>Log Out</code>

{{IconSet|h3|4}} Make sure keyboard gets disconnected from X Window System to [[Login spoofing|defeat login spoofing]]. (unra<code>w</code>) <ref name=unraw-required-questionmark />

[[SysRq]] + <code>w</code>

(Press <code>Alt + SysRq + w</code>)

{{IconSet|h3|5}} Press Secure Access Key also to [[Login spoofing|defeat login spoofing]].

[[SysRq]] + <code>k</code>

(Press <code>Alt + SysRq + k</code>)

{{IconSet|h3|6}} Login as account <code>sysmaint</code>.

{{IconSet|h3|7}} Perform any necessary administrative tasks.

{{IconSet|h3|8}} Logout account <code>sysmaint</code>.

{{IconSet|h3|9}} Re-login as account <code>user</code>.

{{IconSet|h3|10}} Continue usual work as account <code>user</code>.

{{IconSet|h3|11}} Done.
}}

}}

== Substitute User (su) Command ==

The majority of users do not need to utilize the <code>su</code> command. <ref>
<code>su</code> is sometimes incorrectly referred to as the ''superuser'' command. [http://www.linfo.org/su.html It allows]:

<blockquote>
.. 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 <code>root</code> (i.e., administrative) user, thereby providing access to all parts of and all commands on the computer or system.
</blockquote>

By comparison, <code>sudo</code> makes it possible to execute system commands without the <code>root</code> password.
</ref>.

In {{project_name_short}}, by default:

* {{Github_link|repo=security-misc|path=/blob/master/usr/share/pam-configs/wheel-security-misc|text=group <code>sudo</code> membership is required to use <code>su</code>}}. <ref>
Implemented in package [https://github.com/{{project_name_short}}/security-misc security-misc].
</ref>
* Account <code>user</code> is a member of group <code>sudo</code>. ([[Dev/user-sysmaint-split|This might change in a later release.]])

{{Box|text=
To permit the <code>su</code> command from account <code>user</code>, complete the following steps.

([[Qubes|{{q_project_name_short}}]]: perform these steps in {{project_name_gateway_short}} Template.)

{{IconSet|h2|1}} '''[[#Enable Root Account|Enable the <code>root</code> account]].'''

{{IconSet|h2|2}} '''Add account <code>user</code> to group <code>root</code>.'''

{{CodeSelect|code=
sudo adduser user root
}}

{{IconSet|h2|3}} '''[[SUID_Disabler_and_Permission_Hardener#Re-enable_Specific_SUID_Binaries|Re-enable SUID]].'''

Set <code>suid</code>. Note: It is okay if the second command fails.

{{CodeSelect|code=
sudo permission-hardener disable /bin/su
sudo permission-hardener disable /usr/bin/su
}}

<ref>
{{CodeSelect|code=
sudo chmod 4755 /bin/su
sudo chmod 4755 /usr/bin/su
}}
</ref>

{{IconSet|h2|4}} '''[[SUID_Disabler_and_Permission_Hardener#Whitelist_Specific_SUID_Binaries|Add SUID whitelisting]].'''

{{CodeSelect|code=
sudo mkdir -p /etc/permission-hardener.d
}}

{{Open with root rights|filename=
/etc/permission-hardener.d/20_user.conf
}}

Add.

{{CodeSelect|code=
/bin/su exactwhitelist
/usr/bin/su exactwhitelist
}}

{{IconSet|h2|5}} '''Save.'''

{{IconSet|h2|6}} '''Done.'''

Steps to permit <code>su</code> command from account <code>user</code> are complete.
}}
{{Anchor|login}}

== Root Login ==

<code>Root</code> login within a [[Desktop#Virtual_Consoles|virtual console]] will be disabled by default after upgrades. <ref>
security-misc <code>{{Github_link|repo=security-misc|path=/blob/master/etc/securetty.security-misc|text=/etc/securetty}}</code> is empty by default.
</ref> <ref>
When trying to login as <code>root</code> in a [[Desktop#Virtual_Consoles|virtual console]] it will reply: <blockquote>
Login incorrect.</blockquote> Without previously asking for a password. This is not the worst case for usability and is better than asking for password and then failing.
</ref>

To enable login from a [[Desktop#Virtual Console|virtual console]], first apply the [[#Enable Root Account|Enable <code>Root</code> Account]] instructions further above, then complete the steps below.
{{Box|text=
{{IconSet|h2|1}} '''To allow <code>root</code> login, <code>/etc/securetty</code> must be configured. <ref>'''
<code>sudoedit</code> will not follow symlinks, therefore <code>realpath</code> is used.
</ref>

{{Open with root rights|filename=
$(realpath /etc/securetty)
}}

{{IconSet|h2|2}} '''Add the following content.'''

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

* [[{{non_q_project_name_short}}|{{non_q_project_name_short}}]]:
{{CodeSelect|code=
tty1
tty2
tty3
tty4
tty5
tty6
tty7
tty8
tty9
tty10
}}

* [[Qubes|{{q_project_name_short}}]]:
{{CodeSelect|code=
hvc0
}}

{{IconSet|h2|3}} '''Save the file.'''
}}

== Recovery Mode ==
Root login is possible using [[Recovery#Recovery_Mode|recovery mode]]. <ref>
https://forums.whonix.org/t/restrict-root-access/7658/46
</ref>

When the <code>root</code> account is disabled, passwordless <code>root</code> 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 <code>root</code> password would break the rescue and emergency shell. Therefore the [https://github.com/{{project_name_short}}/security-misc security-misc] package enables a passwordless rescue and emergency shell. This is the same solution that Debian will likely adapt for Debian installer. <ref>
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=802211
* /etc/systemd/system/emergency.service.d/override.conf
* /etc/systemd/system/rescue.service.d/override.conf
</ref>

With passwordless <code>root</code> 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|full disk encryption]].

{{anchor|qubes root console}}

== Qubes Root Console ==
The following will open a <code>root</code> console inside a Qubes VM.

Choose an option.

Right click qube and Open console in qube

{{Tab
|type=controller
|content=
{{Tab
|title= === Using qvm-console-dispvm ===
|type=section
|active=true
|content=
Using <code>qvm-console-dispvm</code> might be more secure than <code>qvm-run</code>. <ref>
<code>qvm-console-dispvm</code> runs the terminal-emulator in a Disposable, which can login into a separate [[Desktop#Virtual_Consoles|virtual console]].
</ref>

{{IconSet|h2|1}} '''Open a dom0 terminal.'''

<code>Qubes App Launcher (blue/grey "Q")</code> → <code>System Tools</code> → <code>Xfce Terminal
</code>

{{IconSet|h2|2}} '''Run the following command.''' <ref>
<code>dom0</code>:

* help: {{CodeSelect|inline=true|code=
qvm-console-dispvm --help
}}
* source code:
** {{CodeSelect|inline=true|code=
cat /usr/bin/qvm-console-dispvm
}}
** {{CodeSelect|inline=true|code=
cat /etc/qubes-rpc/admin.vm.Console
}}
</ref>

Note: Replace <code>vm-name</code> with the name of the actual VM where you want to open a <code>root</code> console.

{{CodeSelect|code=
qvm-console-dispvm vm-name
}}

{{IconSet|h2|3}} '''Done.'''

A Qubes <code>root</code> console will now be available.
}}

{{Tab
|title= === Using qvm-run ===
|type=section
|content=
{{IconSet|h2|1}} '''Open a dom0 terminal.'''

<code>Qubes App Launcher (blue/grey "Q")</code> → <code>System Tools</code> → <code>Xfce Terminal
</code>

{{IconSet|h2|2}} '''Run the following command.'''

Note: Replace <code>vm-name</code> with the name of the actual VM where you want to open a <code>root</code> console.

{{CodeSelect|code=
qvm-run -u root vm-name xfce4-terminal
}}

{{IconSet|h2|3}} '''Done.'''

A Qubes <code>root</code> console will now be available.
}}

}}

== Qubes Passwordless Root Access Setup ==
The following can be used to set up passwordless <code>root</code> access for specific Qubes VMs.

{{Box|text=
{{IconSet|h2|1}} '''Open a [[#Qubes Root Console|Qubes <code>Root</code> Console]].'''

{{IconSet|h2|2}} '''Temporary passwordless <code>root</code> access until reboot.'''

Run the following command.

{{CodeSelect|code=
echo "user ALL=(ALL:ALL) NOPASSWD:ALL" {{!}} EDITOR=tee visudo -f /etc/sudoers.d/nopassword >/dev/null
}}

{{IconSet|h2|3}} '''Permanent passwordless <code>root</code> access after reboot.'''

Run the following command.

{{CodeSelect|code=
echo 'echo "user ALL=(ALL:ALL) NOPASSWD:ALL" {{!}} EDITOR=tee visudo -f /etc/sudoers.d/nopassword >/dev/null' {{!}} tee -a /rw/config/rc.local >/dev/null
}}

{{IconSet|h2|4}} '''Make Qubes VM specific startup script <code>/rw/config/rc.local</code> executable.'''

{{CodeSelect|code=
chmod +x /rw/config/rc.local
}}

{{IconSet|h2|5}} '''Done.'''
}}

NOTE: In 17.2.3.8 and above this can be simplified to 1 command.

{{CodeSelect|code=
passwordless-root
}}

{{Anchor|dsudo}}

== dsudo - default password sudo ==
<code>dsudo</code> is a {{project_name_short}} specific feature. <ref>
https://forums.whonix.org/t/dsudo-default-password-sudo/8766
</ref>

As long as still using the [[#Default Password|default password]] (not having [[Post_Install_Advice#Change_Passwords|changed sudo password]]), commands can be run as <code>root</code> without entering a password. This is useful for users having issues with [[Keyboard Layout|changing the keyboard layout]] and for testing VMs.

Instead of using

{{CodeSelect|code=
sudo
}}

use

{{CodeSelect|code=
dsudo
}}

== passwordless-root ==
{{project_name_long}} version <code>17.3.9.9</code> and above comes with [https://github.com/Kicksecure/usability-misc/blob/master/usr/bin/passwordless-root <code>/usr/bin/passwordless-root</code>]. A tool to easily set up passwordless <code>sudo</code> for account <code>user</code>.

Execution of <code>passwordless-root</code> requires administrative ("<code>root</code>") rights.

1. {{sysmaint_notice}}

2. '''Run the passwordless-root command.''' <ref>
When logged in as root (such as when using Qubes or otherwise), <code>sudo</code> is not required for the following command.
</ref>

{{CodeSelect|code=
sudo passwordless-root
}}

3. '''Done.'''

== privleap custom actions ==
Notes:

* Works with {{Cli}} applications only!

'''1.''' Boot into {{BootEntries|key=syspers}}.

Setting this up requires booting into sysmaint mode.

'''2.''' Create file <code>/etc/privleap/conf.d/user-custom.conf</code>.

{{CodeSelect|code=
sudo append-once /etc/privleap/conf.d/user-custom.conf "\
[action:user-custom]
Command=/usr/bin/user-custom
AuthorizedGroups=sudo
AuthorizedUsers=user
"
}}

'''3.''' Check the privleap configuration file is valid.

{{CodeSelect|code=
privleapd --check-config
}}

If there is no output, no error message, then the configuration is valid.

'''4.''' Create executable file <code>/usr/bin/user-custom</code>.

{{Open with root rights
|filename=/usr/bin/user-custom
}}

'''5.''' Paste.

Notes:

* Replace <code>custom-command-here</code> with your actual custom command or commands.
* Advanced users feel free to use other script or programming languages instead.
* Optional: See folder <code>/etc/privleap/conf.d</code> for other examples.

{{CodeSelect|code=
#!/bin/bash

custom-command-here
}}

'''6.''' Make executable.

{{CodeSelect|code=
sudo chmod +x /usr/bin/user-custom
}}

'''7.''' Boot into {{BootEntries|key=userpers}}.

'''8.''' Run the privleap custom action.

{{CodeSelect|code=
leaprun user-custom
}}

'''9.''' Done.

The process is complete.

= Definitions =
== Rooted ==
{{anchor|Definition of Rooted}}
What does it mean to be "<code>rooted</code>"? The word "<code>rooted</code>" in the context of computer security, smartphones, and <code>root</code> isolation is used in different ways.

A device can get "<code>rooted</code>" by at least two different entities:

* '''A)''' user: Intentional <code>rooting</code> by the user grants them full administrative rights and is typically carried out to overcome restrictions imposed by the manufacturer or operating system (e.g., to uninstall bloatware or customize the OS).
* '''B)''' malware: Malware-induced <code>rooting</code> occurs when malicious software exploits vulnerabilities to gain privileged access without user consent, often for nefarious purposes such as installing malicious programs, gaining deeper access to sensitive data, or ensuring malware persistence.

Linux desktop operating system (Debian, Fedora, Kicksecure, Whonix, and most others) specific example:

* '''Definition:''' If <code>sudo</code> is configured to allow account <code>user</code> to run commands without a password, the machine can be considered <code>rooted</code> by the user.
* '''In technical terms:''' File <code>/etc/sudoers.d/user-passwordless</code> contains content <code>user ALL=(ALL:ALL) NOPASSWD:ALL</code>.
* '''Implications:''' This means the user will be able to run <code>sudo some-command</code> to execute a command with administrative ("<code>root</code>") rights without a password. The user could even run <code>sudo su</code> to log into the <code>root</code> account.

Qubes specific example: If package <code>qubes-core-agent-passwordless-root</code> gets installed, then the VM has been <code>rooted</code> by the user. The implications are the same as above. On the other hand, if the user opens a [[Root#Qubes_Root_Console|Qubes <code>Root</code> Console]], the VM should not be considered <code>rooted</code>.

Kicksecure specific example:

* '''A)''' user session: When using [[sysmaint|user-sysmaint-split]] and booting into a user session, the system should not be considered <code>rooted</code> because <code>sudo</code>/<code>root</code> access is unavailable.
* '''B)''' Unrestricted Admin Mode: When enabling [[Unrestricted Admin Mode]], then the system can be considered <code>rooted</code> by the user.
* '''C)''' sysmaint session: When the user boots into sysmaint session, the system should not be considered <code>rooted</code>. Sysmaint session is a temporary, legitimate admin session, does not break the security model and is not the same as Unrestricted Admin Mode. <ref>
Why not considered "rooted" in this case:

* Temporary access: sysmaint session typically provides temporary administrative (root) access for system recovery or maintenance, not persistent unrestricted access.
* Controlled context: It is explicitly initiated by the user for maintenance and does not imply a permanent security model change.
* Security model preserved: Once the system exits sysmaint session, the regular restrictions and security policies resume.
</ref>

Malware specific example: If a web server (such as <code>nginx</code> running under a limited Linux account user <code>nginx</code>) gets compromised, the malware could attempt to <code>root</code> the device (a synonym for saying "<code>root</code> the operating system"). This is also often called local privilege escalation (LPE), which refers to exploiting vulnerabilities, misconfigurations, or using other techniques to escalate permissions from a regular account to a higher privilege level, typically the "<code>root</code>" account. In this case, the web server could be considered <code>rooted</code> by malware.

Android specific example: If the user manages to get an Android <code>Root</code> Management Tool such as SuperSU, Magisk, or Superuser by ChainsDD to be functional, then the device is typically considered "<code>rooted</code> by the user". On the other hand, if a compromised or malicious app accomplishes LPE, then the device can be considered "<code>rooted</code> by malware".

Unclear definitions: What if on a Linux desktop distribution, account <code>user</code> can gain root rights after using <code>sudo</code> and entering a password? Typically, for Linux desktop distributions this is not considered "<code>rooted</code>". The word "<code>rooted</code>" is mostly used on mobile operating systems Android and iOS.

Difference in Terminology:

* '''Desktop Linux''': The concept of "<code>rooting</code>" is not usually applied to traditional Linux desktops. Instead, users elevate privileges with <code>sudo</code>, which is considered a normal administrative function. The term "<code>rooted</code>" implies a fundamental change in the system's security model that is not present when using standard privilege escalation like <code>sudo</code>.
* '''Mobile OS (Android/iOS)''': "<code>Rooting</code>" or "jailbreaking" signifies that the device’s default restrictions are bypassed, giving the user continuous and unrestricted access to system files and functions.

{{Anchor link|Malicious Root Management Tools}} 
Malicious <code>Root</code> Management Tools: Are an Android / iOS specific issue. Some websites say, for example, that KingRoot for Android is malware. <ref>
https://ivonblog.com/en-us/posts/kingroot-is-a-malware/
</ref> This issue does not exist for Linux desktop distributions. Tools such as <code>su</code>, <code>sudo</code>, <code>doas</code> are Open Source, Freedom Software and generally not considered malware. The existence of malicious <code>root</code> management tools and other issues (documented on [[Mobile_Phone_Security#Administrative_Rights|Mobile Devices Privacy and Security, Administrative Rights]]) are among reasons why <code>rooting</code> is often discouraged for mobile devices. However, a blanket recommendation to avoid <code>rooting</code> in all cases for all use cases cannot be deduced from that.

Related:

* [[Miscellaneous_Threats_to_User_Freedom#Administrative_Rights|General Threats to User Freedom, Administrative Rights Refusal]]
* [[Verified Boot]]

== sudoless ==
What does "sudoless" mean? Word definition.

Different people have used the term "sudoless" for very different meanings.

* 2015: [https://gist.github.com/ivandokov/9328c98202b45104fa3e ivandokov/sudoless]: means passwordless <code>sudo</code>. The ability of a specific Linux user account name such as "<code>user</code>" to run <code>sudo</code> without a password.
* 2021: [https://andyyang.co.uk/synology-nas-how-to-run-docker-commands-without-sudo/ How to run Docker commands without sudo on a Synology NAS: A quick guide to enable sudoless docker commands.]
* 2022: [https://forums.kicksecure.com/t/sudoless-kicksecure/139 a Kicksecure user forum post]: used "sudoless" as a synonym for "passwordless".
* 2023: [https://www.techrepublic.com/article/enable-podman-sudoless-container-management/ TechRebuplic: How to enable Podman sudo-less container management]
* 2024: [https://github.com/secureblue/secureblue/releases/tag/v4.2.0 secureblue]: used "sudoless" in context of removal of <code>sudo</code>, <code>su</code> and <code>pkexec</code>. (Related: [[Dev/secureblue|Comparison of secureblue with Kicksecure and Development Notes]], chapter [[Dev/secureblue#sudoless|sudoless]].)

The term "sudoless" can therefore be confusing, should either be avoided or clarified when used.

= See Also =
* [[SysRq|System Recovery using SysRq Key]]
* [[Login spoofing]]
* [[Dev/Strong_Linux_User_Account_Isolation|Strong Linux User Account Isolation]]

= Development =
* {{project_name_short}} code: {{Github_link|repo=security-misc|path=/pull/22|text=Restrict access to the <code>root</code> account}}.
* https://forums.whonix.org/t/sysrq-magic-sysrq-key/8079/68
* https://forums.whonix.org/t/should-lesser-adversaries-with-physical-access-be-part-of-the-threat-model-of-whonix-whonix-host-kicksecure/7997

= Attribution =
{{sdebian
|link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1391
|text=Using sudo
}}

= Footnotes =
{{reflist|close=1}}
[[Category:Documentation]]
{{Footer}}