Safely Use Root Commands

Kicksecure ™

Download

On Computer USB Installation Intel / AMD64 ARM64 Raspberry Pi PPC64 Windows (VM) Mac Linux (VM) VirtualBox (VM) Qubes (VM) KVM (VM) Debian morph to Kicksecure More options Source Code

About

Overview Features Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Forum Best Practices Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Avoid nonfreedom software Documentation sysmaint Previous page: Avoid nonfreedom software Index page: Documentation Next page: sysmaint Safely Use Root Commands

• Default Passwords
• Passwords
• Account Management
• Login
• Login Spoofing
• Safely Use Root Commands
• sysmaint Account
• System Maintenance Panel
• Unrestricted Admin Mode
• Protection against Physical Attacks
• User Account Isolation (developers)
• user-sysmaint-split (developers)
• Polkit (formerly PolicyKit) / pkexec
• privleap / leaprun

This page gives tips on using sudo / root (privileged) commands safely. The root 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 'root' is important, what it is used for, and how to use sudo / root (privileged) commands safely.

Rationale for Protecting the Root Account

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

Quote xkcd authorization:

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.

Quote user discussion:

Most people will consider their home directory as more important than root dirs

Once a malicious program has access to my home folder, I don't 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 measure this is why this documentation recommends compartmentalization, that is, 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 host operating system: If using virtual machines (VM): It is much less likely that malware will break out of a virtual machine if it does not have root access within the VM. This is because root 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 rootkits, which can be very difficult to detect and remove.
• Protect the virtualizer: It is harder to attack the virtualizer without root / 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 hardware backdoor (such as in BIOS or other firmware trojan) 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 non-root users (such as www-data) to access account user 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 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.d (Full System AppArmor Profile) and sandbox-app-launcher.

Kicksecure implements various security hardening to Enforce Strong Linux User Account Isolation.

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

Default Passwords

The default passwords for Kicksecure are:

• Default username: user
• Default password: No password required. (Passwordless login.)

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

Users can change or set a password for security reasons if this is useful in their case based on this Information.

Running with Root Access

Run with Administrative Rights

To run an application with administrative ("root") rights.

1 Sysmaint Notice

Platform specific.

• Kicksecure:
  • If using user-sysmaint-split: The user needs to boot into the sysmaint session. For details and instructions on how to do that, see user-sysmaint-split. (user-sysmaint-split is the default since build version 17.3.9.9.)
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.
• Kicksecure-Qubes:
  • If using user-sysmaint-split: The computer user needs to open a Qubes Root Console.
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.

2 Use a privilege elevation utility to run commands as root.

Note: Replace command with the actual command.

• command line interface (CLI): sudo command
• graphical user interface (GUI): See Graphical Applications with Root Rights.

3 Password entry.

If a password has been configured, the utility will prompt for it.

4 Done.

5 Test command.

Run a test command with administrative ("root") rights.

This is only a simple test to confirm that the user can currently escalate to administrative rights. Type the following command in the terminal and press <Enter>.

sudo whoami

Expected output.

root

User Password versus Root Password

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

Security and Best Practices

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 sudo su.

Inappropriate Use of Root Rights

Do not think of root as a shortcut to fix issues.

It is very much discouraged to establish the following behavior:
application problem → "try sudo / root".

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

Inappropriate Use of root Rights:

• Can cause additional non-security related issues. Related is also later chapter Graphical Applications with Root Rights.
• Risks harmful code being run as root.

Graphical Applications and Root Rights

1 Do not run graphical user interface (GUI) with sudo!

It is discouraged to run graphical user interface (GUI) applications with sudo gui-application.

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

Doing so would be an Inappropriate Use of Root 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.

No protocol specified

cannot connect to X server :0

2 If there is a legitimate reason to start GUI applications with root rights when using X11, use lxsudo instead. Syntax:

lxsudo application-name

For example to start the partition manager gparted by default with root rights.

lxsudo gparted

If there is a legitimate reason to start GUI applications with root rights when using Wayland, see Wayland instructions below.

3 To edit files which can only be edited with root rights. Use the following syntax.

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

Open file /path/to/file/name in an editor with root rights.

Select your platform.

Kicksecure

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit /path/to/file/name

Kicksecure-Qubes

Notes:

• When using Kicksecure-Qubes, this must be done inside the Template.

sudoedit /path/to/file/name

• After applying this change, shut down the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Others and Alternatives

Notes:

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

sudoedit /path/to/file/name

For example:

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

Select your platform.

Kicksecure

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit /etc/default/keyboard

Kicksecure-Qubes

Notes:

• When using Kicksecure-Qubes, this must be done inside the Template.

sudoedit /etc/default/keyboard

• After applying this change, shut down the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Others and Alternatives

Notes:

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

sudoedit /etc/default/keyboard

Polkit PolicyKit pkexec for GUI applications

Use of Polkit (formerly PolicyKit) (pkexec) might also be appropriate for running GUI applications with root rights. Usually such applications should have desktop shortcuts or wrappers which make use of pkexec. There are no (or rare) known cases where users need to run pkexec on the command line.

Wayland

Running GUI applications as root (lxsudo, sudo --set-home, pkexec will be more difficult once Kicksecure has been ported from X11 to Wayland. This is because Wayland requires applications to access $XDG_RUNTIME_DIR/$WAYLAND_SOCKET to open GUI windows. You may run into this when using Other Desktop Environments using Wayland.

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

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:

sudo --set-home XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR QT_QPA_PLATFORM=wayland application-name

Root Account Management

Default Setting

• Root account locked: For security reasons, the root account has been configured into the state of "locked" for login by default in Kicksecure.
• 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 Root Account Locked and Meanings of Special Characters in the Password Field of /etc/shadow File.
• No root usage needed: Most users should not need to use the root account.

Avoid Root Login

Should the user log in as root? No. See footnote for rationale.

Note: Kicksecure is an Implementation of the Securing Debian Manual. Specifically the feature you're reading about here is inspired by this chapter in the manual: Using su

Enable Root Account

If the user wants to enable the root account, run the following commands.

1 Sysmaint Notice

Platform specific.

• Kicksecure:
  • If using user-sysmaint-split: The user needs to boot into the sysmaint session. For details and instructions on how to do that, see user-sysmaint-split. (user-sysmaint-split is the default since build version 17.3.9.9.)
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.
• Kicksecure-Qubes:
  • If using user-sysmaint-split: The computer user needs to open a Qubes Root Console.
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.

2 Platform-specific notice.

• Kicksecure: No special notice.
• Kicksecure-Qubes: Inside kicksecure-17 Template.

3 Choose sudo availability.

sudo available

If you can use sudo, follow the instructions below.

sudo unavailable

If you cannot use sudo:

• Kicksecure: Boot into recovery mode.
• Kicksecure-Qubes: Open a Qubes Root Console.

4 Set a root password.

See configuring passwords for detailed information on changing user account passwords.

Note: These instructions apply to the user account. Replace user with root.

5 Done.

The root account has been unlocked.

Disable Root Account

Applicability:

• Earlier versions: Kicksecure (versions lower than 15.0.0.3.6) came with the root account enabled by default.
• Distro-morphing: Users who installed Kicksecure inside Debian using the installation method described in the User Account Information section.

Most users should disable the root account by running the following commands.

1 Sysmaint Notice

Platform specific.

• Kicksecure:
  • If using user-sysmaint-split: The user needs to boot into the sysmaint session. For details and instructions on how to do that, see user-sysmaint-split. (user-sysmaint-split is the default since build version 17.3.9.9.)
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.
• Kicksecure-Qubes:
  • If using user-sysmaint-split: The computer user needs to open a Qubes Root Console.
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.

2 Platform-specific notice.

• Kicksecure: No special notice.
• Kicksecure-Qubes: Inside kicksecure-17 Template.

3 Lock the root account.

sudo passwd --lock root

4 Done.

The root account has been locked.

In the future, use sudo instead when necessary.

Troubleshooting

Permissions Fix

After inappropriate use of root rights, attempt to fix:

Open a terminal.

Select your platform.

Kicksecure

If you are using a graphical Kicksecure with Xfce, run.

Start menu → Applications → System → Terminal

Kicksecure-Qubes

If you are using Kicksecure-Qubes, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Kicksecure App Qube (commonly named kicksecure) → Xfce Terminal

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

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.

1 Launch a root terminal.

• Kicksecure: Boot into recovery mode.
• Kicksecure-Qubes: Open a Qubes Root Console.

2 Notes.

• This process will be similar to the 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 to Kicksecure. 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.

3 Set a new password.

To change the password for account user, run the following command.

sudo passwd user

4 Reboot.

sudo reboot

5 Done.

The process of password reset has been completed.

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. (This is related to security feature Bruteforcing Linux User Account Passwords Protection.)

1 Launch a terminal that can run commands as root.

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

Platform specific.

• Kicksecure: Boot into recovery mode.
• Kicksecure-Qubes: Open a Qubes Root Console.

2 Run the following command.

Note: Replace user with the actual name of the user that you wish to unlock.

sudo faillock --dir /var/lib/security-misc/faillock --user user --reset

3 Done.

Unlocking of user account has been completed.

Console Unlock

1 Launch a root terminal.

• Kicksecure: Boot into recovery mode.
• Kicksecure-Qubes: Open a Qubes Root Console.

2 Learn the syntax.

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

sudo adduser account-name group-name

3 Add the account to group Linux user group console.

Run the following command.

Note: Replace user with the Linux user account name which should be allowed to login on the login console.

sudo adduser user console

4 Done.

The account has been added to group console.

Advanced Users

Prevent Malware from Sniffing the Root Password

Rationale for Separate sysmaint Account

If Linux user account user is compromised and has sudo access, malware can easily steal the administrative ("sudo") password. Therefore it is more secure (rationale) to perform administrative actions such as running sudo from a separate sysmaint (System Maintenance) account that is less likely to get compromised, since this reduces the chances of malware sniffing the password to escalate to administrative ("root") access.

The basic concept is a separation of the following accounts:

• account user: Perform everyday actions such as running web browsers.
• account sysmaint: Perform system maintenance administrative actions such as installing additional packages.

Questions and answers:

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

Overview of Steps

To more securely perform administrative tasks that require root access, see the following overview steps below. Detailed technical steps are available further below.

1. Prerequisite knowledge: login spoofing
2. These instructions are ideally applied after installing the host / VM when it is still considered free of malware.
3. Only then perform administrative tasks according to the instructions below.

Detailed Steps

1 Check if user-sysmaint-split is already installed.

See sysmaint Default Installation Status.

2 Install the user-sysmaint-split package, if needed.

This is required to create user sysmaint. For instructions, see user-sysmaint-split Installation.

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

Power-off and Power-on Cycle Method

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

1 Power off.

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

2 Power on.

3 See Usage.

4 Perform any necessary administrative tasks.

5 Power off.

6 Power on.

7 Done.

Non-GUI Environment Method

• Advantage: can keep current account session(s) and/or graphical session (X Window System) running.
• Disadvantages:
  • Unsupported. Less secure. (user-sysmaint-split (developers), Fast User Switching)
  • Cannot use graphical session during administrative tasks
  • Requires SysRq, which is disabled by default in Kicksecure for security reasons.

1 Enable SysRq.

2 Make sure keyboard gets disconnected from X Window System to defeat login spoofing. (unraw)

SysRq + w

(Press Alt + SysRq + w)

3 Switch to another virtual console.

(Press Alt + Crtl + F2)

4 Press Secure Access Key also to defeat login spoofing.

SysRq + k

(Press Alt + SysRq + k)

5 Login as account sysmaint from that non-graphical environment (virtual console).

6 Perform any necessary administrative tasks.

7 Logout account sysmaint.

logout

8 Switch back to previous virtual console.

X Window System runs in:

• most Linux distributions: virtual console 7 (Press Alt + Crtl + F7)
• Qubes: virtual console 1 (Press Alt + Crtl + F1)

9 Re-login if needed and continue usual work as account user.

10 Done.

Logout Method

• Advantage:
  • Can use graphical session (X Window System) during administrative tasks using privileged account sysmaint.
• Disadvantages:
  • Unsupported. Less secure. (user-sysmaint-split (developers), Fast User Switching)
  • Cannot keep graphical session of unprivileged account user running. In other words, simplified, all applications run under account user will be terminated.
  • Requires SysRq, which is disabled by default in Kicksecure for security reasons.

1 Enable SysRq.

2 Terminate all running applications in current graphical (X) session.

3 Log out.

Start Menu -> Log Out

4 Make sure keyboard gets disconnected from X Window System to defeat login spoofing. (unraw)

SysRq + w

(Press Alt + SysRq + w)

5 Press Secure Access Key also to defeat login spoofing.

SysRq + k

(Press Alt + SysRq + k)

6 Login as account sysmaint.

7 Perform any necessary administrative tasks.

8 Logout account sysmaint.

9 Re-login as account user.

10 Continue usual work as account user.

11 Done.

Substitute User (su) Command

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

In Kicksecure, by default:

• group sudo membership is required to use su.
• Account user is a member of group sudo. (This might change in a later release.)

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

(Kicksecure-Qubes: perform these steps in Kicksecure Template.)

1 Enable the root account.

2 Add account user to group root.

sudo adduser user root

3 Re-enable SUID.

Set suid. Note: It is okay if the second command fails.

sudo permission-hardener disable /bin/su sudo permission-hardener disable /usr/bin/su

4 Add SUID whitelisting.

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

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

Select your platform.

Kicksecure

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

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

Kicksecure-Qubes

Notes:

• When using Kicksecure-Qubes, this must be done inside the Template.

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

• After applying this change, shut down the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Others and Alternatives

Notes:

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

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

Add.

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

5 Save.

6 Done.

Steps to permit su command from account user are complete.

Root Login

Root login within a virtual console will be disabled by default after upgrades.

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.

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

Select your platform.

Kicksecure

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit $(realpath /etc/securetty)

Kicksecure-Qubes

Notes:

• When using Kicksecure-Qubes, this must be done inside the Template.

sudoedit $(realpath /etc/securetty)

• After applying this change, shut down the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Others and Alternatives

Notes:

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

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.

• Kicksecure:

tty1 tty2 tty3 tty4 tty5 tty6 tty7 tty8 tty9 tty10

• Kicksecure-Qubes:

hvc0

3 Save the file.

Recovery Mode

Root login is possible using recovery mode.

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 package enables a passwordless rescue and emergency shell. This is the same solution that Debian will likely adapt for Debian installer.

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.

See also: Recovery Mode

Qubes Root Console

The following will open a root console inside a Qubes VM.

Choose an option.

Right click qube and Open console in qube

Using qvm-console-dispvm

Using qvm-console-dispvm might be more secure than qvm-run.

1 Open a dom0 terminal.

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

2 Run the following command.

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

qvm-console-dispvm vm-name

3 Done.

A Qubes root console will now be available.

Using qvm-run

1 Open a dom0 terminal.

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

2 Run the following command.

Note: 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

3 Done.

A Qubes root console will now be available.

Qubes Passwordless Root Access Setup

The following can be used to set up passwordless root access for specific Qubes VMs.

1 Open a Qubes Root Console.

2 Temporary passwordless root access until reboot.

Run the following command.

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

3 Permanent passwordless root access after reboot.

Run the following command.

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

4 Make Qubes VM specific startup script /rw/config/rc.local executable.

chmod +x /rw/config/rc.local

5 Done.

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

passwordless-root

dsudo - default password sudo

dsudo is a 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

sudo

use

dsudo

passwordless-root

Kicksecure version 17.3.9.9 and above comes with /usr/bin/passwordless-root. A tool to easily set up passwordless sudo for account user.

Execution of passwordless-root requires administrative ("root") rights.

1. Sysmaint Notice

Platform specific.

• Kicksecure:
  • If using user-sysmaint-split: The user needs to boot into the sysmaint session. For details and instructions on how to do that, see user-sysmaint-split. (user-sysmaint-split is the default since build version 17.3.9.9.)
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.
• Kicksecure-Qubes:
  • If using user-sysmaint-split: The computer user needs to open a Qubes Root Console.
  • If using unrestricted admin mode: This sysmaint notice is not applicable. Continue with the steps below.

2. Run the passwordless-root command.

sudo passwordless-root

3. Done.

privleap custom actions

Notes:

• Works with command line interface (CLI) applications only!

1. Boot into PERSISTENT Mode | SYSMAINT Session | maintenance tasks.

Setting this up requires booting into sysmaint session.

2. Create file /etc/privleap/conf.d/user-custom.conf.

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.

privleapd --check-config

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

4. Create executable file /usr/bin/user-custom.

Open file /usr/bin/user-custom in an editor with root rights.

Select your platform.

Kicksecure

See Open File with Root Rights for detailed instructions on why using sudoedit improves security and how to use it.

Note: Mousepad (or the chosen text editor) must be closed before running the sudoedit command.

sudoedit /usr/bin/user-custom

Kicksecure-Qubes

Notes:

• When using Kicksecure-Qubes, this must be done inside the Template.

sudoedit /usr/bin/user-custom

• After applying this change, shut down the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and is unspecific to Kicksecure-Qubes.

Others and Alternatives

Notes:

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you, or if you are not using Kicksecure, please refer to Open File with Root Rights.

sudoedit /usr/bin/user-custom

5. Paste.

Notes:

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

#!/bin/bash custom-command-here

6. Make executable.

sudo chmod +x /usr/bin/user-custom

7. Boot into PERSISTENT Mode | USER Session | power user activities.

8. Run the privleap custom action.

leaprun user-custom

9. Done.

The process is complete.

Definitions

Rooted

What does it mean to be "rooted"? The word "rooted" in the context of computer security, smartphones, and root isolation is used in different ways.

A device can get "rooted" by at least two different entities:

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

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

Kicksecure specific example:

• A) user session: When using user-sysmaint-split and booting into a user session, the system should not be considered rooted because sudo/root access is unavailable.
• B) Unrestricted Admin Mode: When enabling Unrestricted Admin Mode, then the system can be considered rooted by the user.
• C) sysmaint session: When the user boots into sysmaint session, the system should not be considered rooted. Sysmaint session is a temporary, legitimate admin session, does not break the security model and is not the same as Unrestricted Admin Mode.

Malware specific example: If a web server (such as nginx running under a limited Linux account user nginx) gets compromised, the malware could attempt to root the device (a synonym for saying "root 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 "root" account. In this case, the web server could be considered rooted by malware.

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

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

Difference in Terminology:

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

Malicious Root Management Tools
Malicious Root Management Tools: Are an Android / iOS specific issue. Some websites say, for example, that KingRoot for Android is malware. This issue does not exist for Linux desktop distributions. Tools such as su, sudo, doas are Open Source, Freedom Software and generally not considered malware. The existence of malicious root management tools and other issues (documented on Mobile Devices Privacy and Security, Administrative Rights) are among reasons why rooting is often discouraged for mobile devices. However, a blanket recommendation to avoid rooting in all cases for all use cases cannot be deduced from that.

Related:

• 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: ivandokov/sudoless: means passwordless sudo. The ability of a specific Linux user account name such as "user" to run sudo without a password.
• 2021: How to run Docker commands without sudo on a Synology NAS: A quick guide to enable sudoless docker commands.
• 2022: a Kicksecure user forum post: used "sudoless" as a synonym for "passwordless".
• 2023: TechRebuplic: How to enable Podman sudo-less container management
• 2024: secureblue: used "sudoless" in context of removal of sudo, su and pkexec. (Related: Comparison of secureblue with Kicksecure and Development Notes, chapter sudoless.)

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

See Also

• System Recovery using SysRq Key
• Login spoofing
• Strong Linux User Account Isolation

Development

• Kicksecure code: Restrict access to the root 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

Note: Kicksecure is an Implementation of the Securing Debian Manual. Specifically the feature you're reading about here is inspired by this chapter in the manual: Using sudo

Footnotes

Avoid nonfreedom software Documentation sysmaint Previous page: Avoid nonfreedom software Index page: Documentation Next page: sysmaint

Kicksecure A secure by default operating system with the latest security research in place.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Kicksecure is proudly supported until 2026 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Kicksecure we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2025 ENCRYPTED SUPPORT LLC

Your support makes
all the difference!

We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!