user-sysmaint-split
user-sysmaint-split
- Role-Based Boot Modes - Persistent User / Live user / Persistent sysmaint (system maintenance) and their use cases.
Introduction[edit]
This page discusses different boot modes in the Kicksecure operating system, aimed at improving security through role-based boot options. It describes modes like "Persistent User" for daily activities and "Persistent System Maintenance (sysmaint)" for updates, software installation, and full system control. The goal is to isolate user activities and reduce security risks by restricting what each boot mode can access and modify. The page also explains potential opt-outs for users who prefer traditional root access.
These schemes are generic and work for both hosts and VMs. This applies to Kicksecure and derivatives of Kicksecure, such as Whonix®.
Development Goals[edit]
These goals guide the boot modes implementation:
- Defeat login spoofing
- Prevent Malware from Sniffing the Root Password
- Strong Linux User Account Isolation
- Noexec
- Verified Boot
Grub Default Boot Menu Entries[edit]
The default GRUB boot menu entries are:
PERSISTENT mode USER (For daily activities.)
LIVE mode USER (For daily activities.)
PERSISTENT mode SYSMAINT (For system maintenance.)
Use Cases for the Different Boot Modes[edit]
Common use cases tailored to the available boot modes:
PERSISTENT mode USER (For daily activities.)
:- Ideal for browsing, email, chat, or running a pre-configured server.
- read-only
/usr
,/etc
. - read-write
/home
- Verified Boot: enabled. (Planned.)
LIVE mode USER (For daily activities.)
: Similar to Persistent User but without persistence.PERSISTENT mode SYSMAINT (For system maintenance..)
: Allows runningsudo apt install [package]
, editing/etc/apt/sources.list.d
, and similar tasks. Reboot into USER mode afterward.- read-write
/usr
,/etc
,/home
- Verified Boot: disabled
- read-write
Boot Modes Comparison Table[edit]
Feature | PERSISTENT mode USER
|
LIVE mode USER
|
PERSISTENT mode SYSMAINT
|
---|---|---|---|
Description | For daily activities such as browsing, email, chat, or running a pre-configured server. | Similar to Persistent User but without persistence. | For system maintenance tasks such as running sudo apt install [package] , editing /etc/apt/sources.list.d , and similar tasks. Reboot into USER mode afterward.
|
File System Access: /usr , /etc
|
No, read-only | No, read-only | Yes, read-write |
File System Access: /home
|
Yes, read-write | No, read-only | Yes, read-write |
Verified Boot (planned) | Yes, Enabled | Yes, Enabled | No, Disabled |
Integration with Verified Boot[edit]
When booting into PERSISTENT mode SYSMAINT, verified boot will be disabled for the purpose of updates, software installation, and system configuration. During shutdown, the checksums required for verified boot will be created.
When booting into USER, verified boot will be enabled for the purpose of improved security.
See also Verified Boot for User but not for sysmaint.
planned: Role-Based Boot Modes (user
versus sysmaint
) will be implemented first. Verified boot is an additional security feature that is planned to be implemented later.
No Access to Privilege Escalation Tools for Limited Users[edit]
There are conceptually two groups of users, sysmaint users and limited users.
sysmaint users:
root
sysmaint
Limited users:
user
nginx
mysql
sdwdate
ntp
- Not a member of groups
root
,sudo
, orwheel
. - etc.
It is planned that,
- A) user "
user
" is no longer a member of groupsudo
by default, and; - B) limited Linux user accounts such as user "
user
" will no longer have access to any of the following Privilege Escalation Tools applications:sudo
su
doas
pkexec
This is because Privilege Escalation Tools are SUID applications, which can be a security risk for local privilege escalation (such as from user
to root). SUID related risks are elaborated on the SUID Disabler and Permission Hardener wiki page.
Prerequisite Knowledge:
- Linux file system permission basics.
owner
(u
)group
(g
)others
(o
) (public)read
(r
)write
(w
)execute
(x
)
Comparison:
Debian: Privilege Escalation Tools (such as sudo
and similar programs) are, as per Debian default, owned by user root
and group root
. These can be read
and execute
by owner
, group
, and others
. (chmod 755
)
chmod-calc /usr/bin/sudo
Permissions for: /usr/bin/sudo Type: Regular File Owner: root Group: root Octal Permissions: 755 File Size: 281624 bytes Link Count: 1 Hidden File: No ACLs: none Extended Attributes: none Capabilities: None Immutable (chattr +i): No Category Read Write Execute Owner Yes Yes Yes Group Yes No Yes Public Yes No Yes Special Attributes: SUID: Set SGID: Not Set Sticky Bit: Not Set
Kicksecure Future: Privilege Escalation Tools will be owned by group sysmaint
. others
(which includes user user
) will no longer have read
or execute
rights. (chown root:sysmaint /usr/bin/sudo
; chmod o-rw /usr/bin/sudo
; same for /bin/sudo
)
Group: sysmaint Category Read Write Execute Owner Yes Yes Yes Group Yes No Yes Public No No No
Implementation Plan:
For this to happen, applications may no longer internally use sudo
exceptions (e.g., /etc/sudoers.d
). This is further detailed on the Dev/sudo page.
Opt-Out to Get the Same Behavior as Old Kicksecure[edit]
Users who wish "the old Kicksecure" "with unrestricted sudo
for user user
" back, who don't want the
PERSISTENT mode SYSMAINT (For system maintenance tasks.)
boot option, could uninstall package user-sysmaint-split
. It could be easily removed using dummy-dependency
.
dummy-dependency --purge user-sysmaint-split
(dummy-dependency
is being used to avoid issues with meta package removal.)
Boot Modes Considered Too Unimportant to Be Added to GRUB Default Boot Menu[edit]
Currently, we don’t see good use cases to include these modes as default, but user feedback could change this in the future.
LIVE mode SYSMAINT
DIY Methods to Include These and Other Entries in the GRUB Boot Menu
A Files in the /etc/grub.d/
folder could add these entries, but they could be non-executable by default. To opt-in, users could run sudo chmod +x /etc/grub.d/somenumber_name-of-boot-mode
.
B Users wanting custom entries can add them directly to the /etc/grub.d/
folder or GRUB boot menu.
C Using GRUB boot menu editing (key e
) at boot, kernel parameters can be adjusted for any combination.
/etc/grub.d File Names[edit]
Details about /etc/grub.d
files:
filename purpose --------------------------------------- ----------------------------- /etc/grub.d/10_linux PERSISTENT mode USER /etc/grub.d/11_linux_live LIVE mode USER /etc/grub.d/12_linux_sysmaint PERSISTENT mode SYSMAINT
Files should remain in lexical order below /etc/grub.d/20_
to avoid conflicts with existing scripts.
Note: Some files may not be created initially (or at all), as outlined in the "Boot Modes Considered Too Unimportant to Be Added to GRUB Default Boot Menu" section.
Server Support[edit]
GRUB boot menus aren’t easily accessible on many servers. A solution for making these boot modes available on servers is yet to be determined.
user-sysmaint-split
will not be installed by default on servers. Meta package kicksecure-host-xfce
will come with user-sysmaint-split
by default but meta package kicksecure-host-cli
won't.
Future work ideas:
- See the forum discussion: https://forums.whonix.org/t/multiple-boot-modes-for-better-security-persistent-user-live-user-persistent-admin-persistent-superadmin-persistent-recovery-mode/7708/50
- A) User could create a file that requests booting into sysmaint mode next time.
- B) Sysmaint mode would use a systemd unit drop-in to disable most systemd units, except SSH, etc.
Qubes Support[edit]
Package qubes-core-agent-passwordless-root
will be no longer installed by default in Kicksecure for Qubes.
Todo[edit]
issues with sysmaint mode:
- systemd units running providing attack surface (think long running file downloads/uploads)
- start menu offering Firefox etc.
- ability to run Firefox etc. from the terminal emulator
ideas:
- minimal GUI
- chroot based: complex, messy, two systems to upgrad
- You have to get the disk mounts just right or else you will end up with bootloader upgrades and the like failing
- You have to potentially deal with encryption and LVM, maybe even RAID and other weird setups
- You have two systems to update, which is hard
- a target similar to
single
user mode but not really single user mode to avoid issues with real single user mode - start minimal services only when booting into sysmaint mode
single
user mode kernel parameter?- https://packages.debian.org/policy-rcd-declarative-deny-all
- a global
ConditionKernelCommandLine=boot-role=sysmaint
that applies to all systemd units?
- Start Menu: Hide Firefox and other similar applications when booting into sysmaint mode.
- A systray icon could display an sysmaint symbol to indicate the mode.
- Add a warning:
- When starting Firefox in sysmaint mode, a popup message should inform the user to avoid browsing the internet unless absolutely necessary.
- Address the challenge of reading documentation after booting into sysmaint mode:
- Why read documentation in sysmaint mode?
- This is often necessary when performing complex system maintenance tasks.
- For online searches or resolving issues.
- Using AI assistants.
- Posting on forums.
- Why read documentation in sysmaint mode?
Offline Documentation is helpful but an insufficient solution.
- Offline documentation often links extensively to upstream resources.
- Users are encouraged to look up online documentation whenever possible (referring to upstream resources).
Alternatives:
- Ideally, users should perform such tasks on a separate computer.
- These alternatives might seem impractical but are safer.
- A less ideal, but safer option is to use a VM for such tasks.
Implementation[edit]
Prior Versions[edit]
Older concept version still containing "SUPERADMIN" and "SECUREADMIN".
Tickets[edit]
- Create user admin by default and add user admin to group sudo by default
- Selective sudo Access Enabling in VMs Without qubes-core-agent-passwordless-root via qvm-service
Related[edit]
- Disable newly (all) installed services by default
- Verified Boot
Forum discussion: AppArmor for Complete System - Including init, PID1, Systemd, Everything! - Full System MAC policyAppArmor for everything: APT, systemd, init, all systemd units, all applications. Mandatory Access Control. Security Hardening.Untrusted Root - Improve Security by Restricting Root
Attribution[edit]
Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manual, chapter Mounting partitions the right way
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 12 year success story and maybe DONATE!