{{Header}}
{{Title|
title=sysmaint - System Maintenance User
}}
{{#seo:
|description=Sysmaint, or system maintenance, is an account created by the [[sysmaint|<code>user-sysmaint-split</code>]] feature. It increases security. Read about this new feature, how to use it and about our rationale on this page. "permission denied: sudo"
|image=Usersysmaint-clipart.svg
}}
{{passwords_mininav}}
[[File:Usersysmaint-clipart.svg|thumb|200px]]
{{intro|
Sysmaint, or system maintenance, is an account created by the [[sysmaint|<code>user-sysmaint-split</code>]] feature. It increases security. Read about this new feature, how to use it and about our rationale on this page.

In case you are wondering how to fix:

<pre>
permission denied: sudo
</pre>
}}
= Screenshot =
'''Image:''' ''Kicksecure - sysmaint Boot Option in [[Grub|GRUB]] Boot Menu''

[[File:kicksecure-persistent-mode-sysmaint-session.png|Persistent Mode - Sysmaint Session - GRUB Boot Menu Option]]

= Overview: What is sysmaint and Why Should I Care? =
Starting from version <code>17.3.9.9</code>, {{project_name_short}} comes with a security feature called [[sysmaint|<code>user-sysmaint-split</code>]] enabled by default (in Xfce and above). This feature creates two separate user accounts:

* <code>user</code> - for daily activities like browsing, writing documents, etc.
* <code>sysmaint</code> - short for '''system maintenance'''; used for tasks that require administrative rights such as installing or updating software.

This separation improves security. For example, if malware compromises your web browser in the <code>user</code> session, it won't have permission to make critical system changes or install rootkits (malicious software that can hide in the system).

You only use the <code>sysmaint</code> account when you want to change system behavior - such as adding new programs, applying updates, or performing administrative tasks.

The opposite of <code>user-sysmaint-split</code> is [[unrestricted_admin_mode|Unrestricted Admin Mode]], which allows the <code>user</code> account to use administrative tools like <code>sudo</code> directly. This is less secure and not enabled by default, but it can be configured if it better suits your use case.

([[Root#Rationale_for_Separate_sysmaint_Account|Read our rationale here]].)

= Real-World Example Use Cases =

* '''You want to install a new application:'''
** Reboot into the <code>sysmaint</code> account to perform the installation.
** Once done, reboot back into your regular desktop account.
* '''You want to install system updates:'''
** Boot into <code>sysmaint</code> mode and run the updates from the System Maintenance Panel.
* '''You want to avoid malware affecting system settings:'''
** Use your regular <code>user</code> account for browsing and daily work. Since it doesn’t have admin access, it's harder for malware to deeply damage your system.

= Default Installation Status =

* '''Old versions:''' {{project_name_short}} [[Systemcheck#Build_Version|build version]] up to version <code>17.2.8.5</code> will <u>not</u> automatically include <code>user-sysmaint-split</code>. However, users can choose to install it manually (see [[#Installation]]). It will likely be included by default when upgrading to a new major version (e.g., version <code>18</code>).
* '''New versions:'''
** '''host:''' Includes <code>user-sysmaint-split</code> by default.
** '''{{cli}}:''' The <code>kicksecure-host-cli</code> meta package does <u>not</u> include <code>user-sysmaint-split</code> by default.
** '''servers:''' <code>user-sysmaint-split</code> is not installed by default on servers.
** '''[[Distribution Morphing]]:''' Not installed by default. Will be installed by default for GUI version starting from version <code>18</code>.

= Version Overview =
{{gui}} versus {{cli}}.

{| class="wikitable"
! Feature
! [[Kicksecure]] Xfce (GUI)
! [[Kicksecure]] CLI
|-

! <code>user-sysmaint-split</code>
| {{Yes}}, installed by default in new images.
| {{No}}, not installed by default.
|-

! Old Versions
| {{No}}, will not be automatically installed during the Kicksecure <code>17</code> release cycle to avoid breaking existing user workflows.
| {{No}}, not applicable, will remain <code>sudo</code> passwordless by default.
|-

! New Images
| {{Yes}}, will come with <code>user-sysmaint-split</code> installed by default.
| {{No}}, <code>user-sysmaint-split</code> will not be included.
|-

! [[Release Upgrade]]
| {{Yes}}, <code>user-sysmaint-split</code> will be installed by default.
| {{No}}, <code>user-sysmaint-split</code> will not be included.
|-

! Opt-Out
| {{Yes}}, supported via {{kicksecure_wiki
|wikipage=unrestricted_admin_mode
|text=Unrestricted Admin Mode
}}.
| {{Yes}}
|-

! Opt-In
| {{Yes}}, <code>user-sysmaint-split</code> can be installed at any time.
| {{Yes}}
|-

|}

= Installation =
{{Install Package
|package=user-sysmaint-split sysmaint-panel
}}

= Usage =
{{IconSet|h2|1}} Platform specific.

Select your platform.

{{Tab
|type=controller
|linkid=os
|content=
{{Tab
|type=section
|title= == {{project_name_short}} ==
|image=[[File:{{project_name_short}}-logo-icon.svg]]
|content=
[[File:System-maintenance-panel.png|thumb|The sysmaint desktop session.]]
[[File:Sysmaint-tty.png|thumb|The sysmaint console session.]]

When <code>user-sysmaint-split</code> is installed, the account <code>user</code> will no longer be able to use privilege escalation tools (<code>sudo</code>, <code>su</code>, <code>pkexec</code>) when logged into any account other than <code>sysmaint</code>.

This change takes effect immediately.

To perform system maintenance tasks such as checking for software updates, installing updates, etc, the user will have to reboot into the <code>sysmaint</code> account. To do this, restart the system normally, then select {{BootEntries|key=syspers}} from the boot menu.

'''Figure:''' ''Persistent Mode - Sysmaint Session - GRUB Boot Menu Option''

[[File:kicksecure-persistent-mode-sysmaint-session.png|Persistent Mode - Sysmaint Session - GRUB Boot Menu Option|600px]]

The system will boot into a minimal desktop session with the [[System_Maintenance_Panel|System Maintenance Panel]] running.

'''Figure:''' ''System Maintenance Panel''

[[File:Sysmaint-panel.png|System Maintenance Panel|600px]]

To reduce attack surface, most superfluous background services are suppressed while booted into the <code>sysmaint</code> account.

The <code>sysmaint</code> desktop session is intentionally minimal and not suited for normal desktop use. This is to discourage using it for work that has a higher risk of causing a difficult-to-avoid system compromise (such as web browsing). Quick shortcuts are provided for simple software management and system administration tasks, while more advanced tasks can be performed from a terminal. The <code>sudo</code> and <code>pkexec</code> commands will be usable here.

Once you are done with system maintenance tasks, click "Reboot" to reboot the system. Then boot into {{BootEntries|key=userpers}} or {{BootEntries|key=userlive}}. This will provide you with a standard desktop session.

When booted in {{BootEntries|key=syspers}}, you can also log into the <code>sysmaint</code> account from a [[Desktop#Virtual_Consoles|virtual consoles]] (<code>tty</code>). Simply input the account name <code>sysmaint</code> at the login prompt. This session behaves identically to a typical virtual console session. A short informational message will be printed after login reminding you that the <code>sysmaint</code> account must be used with caution.
}}

{{Tab
|type=section
|title= == {{q_project_name_long}} ==
|image=[[File:Qubes-logo-icon.png]]
|content=
{{IconSet|h2|2}} Qubes version specific.

Select your Qubes version.

{{Tab
|type=controller
|content=
{{Tab
|type=section
|title= === Qubes R4.2 ===
|content=
<u>In Qubes OS R4.2 and earlier:</u> {{q_project_name_long}} cannot be booted into sysmaint mode. However, <code>user-sysmaint-split</code> is useful in Qubes VMs too because it makes SUID privilege escalation tools (<code>sudo</code>, <code>su</code>, <code>pkexec</code>) inaccessible for account <code>user</code>. You can access the <code>root</code> account by opening a [[Root#Qubes_Root_Console|Qubes Root Console]].
}}

{{Tab
|type=section
|title= === Qubes R4.3 ===
|content=
<u>Qubes OS R4.3 and later:</u>

* <u>Boot modes support:</u> Support [https://github.com/QubesOS/qubes-issues/issues/9750 boot modes].
** <u>Usage of boot modes:</u> {{q_project_name_long}} uses these to allow {{project_name_short}} any Qube to be booted in either {{BootEntries|key=userpers}} or {{BootEntries|key=syspers}}.
* <u>Template:</u> <code>{{project name workstation template}}</code> Template will boot in {{BootEntries|key=syspers}}.
* <u>App Qubes:</u> <code>{{project name workstation short}}</code> App Qubes and Disposables will boot in {{BootEntries|key=userpers}}.
* Comparison with non-Qubes:
** {{BootEntries|key=userpers}} and {{BootEntries|key=syspers}} are mostly functionally identical under Qubes OS. {{BootEntries|key=syspers}} differs in the following ways:
** The default user account for most actions is changed to <code>sysmaint</code>.
** User-specific system services such as the X11 server run as account <code>sysmaint</code>.
** Potentially dangerous operations such as opening URLs are disabled.
** The [[System Maintenance Panel]] is usable.
** Privilege escalation tools are easily usable, since the <code>sysmaint</code> account will be provided rather than the <code>user</code> account.

It is possible to boot a {{project_name_short}} Qube in a non-standard boot mode (i.e. booting a Template in {{BootEntries|key=userpers}}, or booting an AppVM in {{BootEntries|key=syspers}}). To do so, change the boot mode of the Qube before starting it.

{{Box|text=
'''1.''' Ensure the Qube is shut down.

'''2.''' Open Qube Manager.

<code>Start menu</code> &rarr; <code>Gear icon</code> &rarr; <code>Qubes Tools</code> &rarr; <code>Qube Manager</code>

'''3.''' Click on the VM you wish to change the boot mode of.

'''4.''' Click "Settings" in the toolbar.

'''5.''' Click the "Advanced" tab in the Settings window.

'''6.''' In the "Kernel" section, change "Boot mode" to your desired boot mode.

'''7.''' Click "OK" in the Settings window.

'''8.''' Start the Qube. It will boot in the selected boot mode.

'''9.''' Done.

The procedure of switching the boot mode for a Qube is now complete.
}}
}}

}}
}}

}}

= Fast User Switching =
Platform specific. Select your platform.

{{Tab
|type=controller
|linkid=os
|content=
{{Tab
|type=section
|title= == {{project_name_short}} ==
|image=[[File:{{project_name_short}}-logo-icon.svg]]
|content=
'''Reboot into <code>sysmaint</code> session is required, as documented above.'''

<u>Note:</u> It is [[unsupported]] to switch from account <code>user</code> to <code>sysmaint</code> using:

* Start Menu &rarr; logout
* Start Menu &rarr; switch user

This is a security feature. <ref>
[[Dev/user-sysmaint-split#Fast_User_Switching|<code>user-sysmaint-split</code> (developers), Fast User Switching]]
</ref>
}}

{{Tab
|type=section
|title= == {{q_project_name_long}} ==
|image=[[File:Qubes-logo-icon.png]]
|content=
Not applicable.
}}

}}

= Running services in sysmaint sessions =

When booted in {{BootEntries|key=syspers}}, only the minimum services needed for the session to be usable are started by default. New services are prevented from automatically starting during APT software upgrades.

While enabling additional services within the sysmaint session is generally discouraged, it may be necessary in some situations. Services can be started either temporarily for one sysmaint session, or persistently for all sysmaint sessions.

To start a service for the current sysmaint session:

{{Box|text=
Note: Replace <code>service-name</code> in the below steps with the name of the service you are starting. For instance, if you are configuring <code>openvpn.service</code>, replace all instances of <code>service-name</code> with <code>openvpn</code>.

'''1.''' Open a terminal by clicking <code>Open Terminal</code> in the System Maintenance Panel.

'''2.''' Type <code>sudo systemctl start service-name.service</code>

'''3.''' Done.

The procedure of starting a service for one sysmaint session is complete.
}}

To enable a service persistently, so that it autostarts on every sysmaint session boot:

{{Box|text=
Note: Replace <code>service-name</code> in the below steps with the name of the service you are configuring. For instance, if you are configuring <code>openvpn.service</code>, replace all instances of <code>service-name</code> with <code>openvpn</code>.

'''1.''' Open a terminal by clicking <code>Open Terminal</code> in the System Maintenance Panel.

'''2.''' Navigate to the directory containing the systemd unit for to the service you wish to enable. Usually, this will be <code>/usr/lib/systemd/system</code> or <code>/etc/systemd/systemd</code>.

'''3.''' Create a new configuration directory for the service by running <code>sudo mkdir -p service-name.service.d</code>.

'''4.''' Enter the directory you just created by running <code>cd service-name.service.d</code>.

'''5.''' Create a new configuration file for the service by running <code>sudo nano 99_sysmaint-enable.conf</code>.

'''6.''' Type the following lines into the configuration file:

{{CodeSelect|code=
[Install]
WantedBy=sysmaint-boot.target
}}

'''7.''' Press <code>Ctrl+S</code> to save the file, then press <code>Ctrl+X</code> to exit the text editor.

'''8.''' Reload systemd unit configuration files by running <code>sudo systemctl daemon-reload</code>.

'''9.''' Fully enable the service by running <code>sudo systemctl enable service-name.service</code>.

'''10.''' Ensure the <code>systemctl enable</code> command output the following notice. If you see this, it indicates that the service has been successfully enabled.

<pre>
Created symlink /etc/systemd/system/sysmaint-boot.target.wants/service-name.service → /lib/systemd/system/service-name.service.
</pre>

'''11.''' Start the service in the current sysmaint session by running <code>sudo systemctl start service-name.service</code>.

'''12.''' Done.

The procedure of persistently enabling and starting a service in sysmaint mode is now complete.
}}

= Notes =

* ''' <code>sysmaint</code> account restrictions''': Several restrictions are imposed to reduce the risk of the <code>sysmaint</code> account becoming compromised:
** '''Locked access depending on boot mode''': The <code>sysmaint</code> account is locked and cannot be logged into when booted into modes other than {{BootEntries|key=syspers}}.
** '''Session limitation''': Logging into the <code>sysmaint</code> account using anything other than the special <code>sysmaint</code> desktop session is prohibited.
** '''Discouragement of other logins''': When booted in {{BootEntries|key=syspers}}, you will be discouraged (but not entirely prevented) from logging into accounts other than <code>sysmaint</code>. Locking accounts such as account <code>user</code> is not implemented, since doing so would make it very tricky or even impossible for the user to permanently lock accounts themselves.
** '''Inhibition of non-critical services''': When booted in {{BootEntries|key=syspers}}, only the minimum services needed for the session to be usable are started by default. New services are prevented from automatically starting during APT software upgrades.

= Questions and Answers =
* Why is there a separate <code>sysmaint</code> account?
** See [[Root#Rationale_for_Separate_sysmaint_Account|Rationale for Separate <code>sysmaint</code> Account]].

* Why is it required to boot into <code>sysmaint</code> mode, why not simply use start menu &rarr; switch user? ([[Sysmaint#Fast_User_Switching|Fast User Switching]])
** This is to mitigate [[login spoofing]] attacks and to to prevent [[Dev/Strong_Linux_User_Account_Isolation#sudo_password_sniffing|<code>sudo</code> password sniffing]].

* How to go back to [[unrestricted admin mode]], where account <code>user</code> can use <code>sudo</code>?
** See [[#Uninstallation]].

= user-sysmaint-split - GUI vs CLI - Default Installation Status Differences =

<code>user-sysmaint-split</code> is different for the {{gui}} versus the {{cli}} version.

In the future, the CLI version will be improved to be more suitable for servers.

Server support for <code>user-sysmaint-split</code>, however, isn't as sophisticated yet as it is for the GUI version. For some server use cases, <code>user-sysmaint-split</code> may be less needed or unneeded. This topic is elaborated in the development chapter {{kicksecure_wiki
|wikipage=Dev/user-sysmaint-split#Server_Support
|text=<code>user-sysmaint-split</code> Server Support
}}.

= Applications requiring Administrative Rights during User Session =

If it is unsuitable to run some applications in the sysmaint session, then this could be difficult. This is because historically, Freedom Software Linux desktop distributions did not have a strong [[Dev/user-sysmaint-split|<code>user-sysmaint-split</code>]].

There might be many cases where applications should be run in the user session, but this is not possible because some aspect of the application requires [[root|administrative ("<code>root</code>") rights]].

'''Options:'''

* '''A)''' '''<code>privleap</code> custom actions:''' If it's possible to do this on the {{cli}}, [[Advanced Users]] could consider configuring [[Root#privleap_custom_actions|privleap custom actions]].
* '''B)''' '''[[Unrestricted admin mode]]:''' This mode disables the separation between the user and system maintenance roles, allowing the user to directly perform administrative tasks without needing to switch contexts. It provides more flexibility for tasks requiring elevated privileges but at the cost of reduced compartmentalization and security. This approach might be more suitable in environments where usability or workflow requirements outweigh the benefits of strict privilege separation. See [[Unrestricted_admin_mode#Uninstalling_user-sysmaint-split_and_Enabling_Unrestricted_Admin_Mode|Uninstalling user-sysmaint-split and Enabling Unrestricted Admin Mode]].
* '''C)''' '''Use multiple {{VMs}}:''' For compartmentalization. Select VMs that require administrative ("<code>root</code>") rights could use unrestricted admin mode. Others could keep <code>user-sysmaint-split</code>.

'''Issues:'''

* [https://forums.whonix.org/t/zulucrypt-not-working-in-user-session/21609 ZuluCrypt not working in user session]
* [https://forums.kicksecure.com/t/veracrypt-containers-do-not-open/1091 Veracrypt containers do not open]
** [https://forums.whonix.org/t/whonix-user-isolation-user-sysmaint-split-breaks-veracrypt-workflow/21629 Whonix user isolation (user-sysmaint-split) breaks VeraCrypt workflow]
* [https://forums.kicksecure.com/t/struggling-with-the-point-release-update-user-sysmaint-split-sudo/1051 Struggling with the point release update - user-sysmaint-split - sudo]

= Advanced Topics =
For [[Advanced Users]].

== enable sudo access in USER session ==
{{IconSet|h2|1}} Warnings.

* For debugging or advanced users only.
* Enabling <code>sudo</code> access during USER session can be a security issue.
* This is often unnecessary. [[#Uninstallation|Uninstallation of the <code>user-sysmaint-split</code> package]] might be better.

{{IconSet|h2|2}} Boot into {{BootEntries|key=syspers}}.

Setting this up requires booting into <code>sysmaint</code> session.

{{IconSet|h2|3}} Create file <code>/etc/privleap/conf.d/privleap-debugging.conf</code>.

{{CodeSelect|code=
sudo append-once /etc/privleap/conf.d/privleap-debugging.conf "\
[action:sudo]
Command=chmod o+x /usr/bin/sudo
#Command=/usr/libexec/helper-scripts/sudo-tools-enable
AuthorizedGroups=sudo
AuthorizedUsers=user
"
}}

{{IconSet|h2|4}} Boot into {{BootEntries|key=userpers}}.

{{IconSet|h2|5}} Enable <code>sudo</code>.

{{CodeSelect|code=
leaprun sudo
}}

{{IconSet|h2|6}} Notice.

Above command can be run whenever required to enable <code>sudo</code>.

<code>sudo</code> access will be automatically disabled after installing or removing a package using APT. This is because this triggers [[SUID Disabler and Permission Hardener]], which will re-disable <code>sudo</code>, unless an <code>/etc/permission-hardener.d</code> configuration folder snippet gets added.

{{IconSet|h2|7}} Use of <code>sudo</code>.

<code>sudo</code> can be used normally. For example:

{{CodeSelect|code=
sudo touch /etc/testfile
}}

{{IconSet|h2|8}} Done.

The process is complete.

= Uninstallation =
See [[Unrestricted_admin_mode#Uninstalling_user-sysmaint-split_and_enabling_Unrestricted_Admin_Mode|Uninstalling user-sysmaint-split and enabling Unrestricted Admin Mode]].

= Known Issues =

* Qubes has potential local privilege escalation issue: [https://github.com/QubesOS/qubes-issues/issues/9717 harden insecure permissions inside <code>/dev/xen</code> folder / research security impact of the Qubes <code>/dev/xen</code> folder permissions #9717] -- This issue is [[unspecific|unspecific to {{project_name_short}}]] and is entirely unrelated to {{project_name_short}}. It equally applies to App Qubes that are not using <code>qubes-core-agent-passwordless-root</code> such as Qubes Debian minimal Template.

= Developers =
* [[Dev/Strong_Linux_User_Account_Isolation|User Account Isolation (developers)]]
* [[Dev/user-sysmaint-split|<code>user</code>-<code>sysmaint</code>-split (developers)]]
* https://github.com/Kicksecure/user-sysmaint-split
* https://github.com/Kicksecure/sysmaint-panel

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