user-sysmaint-split

From Kicksecure
< Dev
(Redirected from Dev/boot modes)
Jump to navigation Jump to search
Design Previous page: Dev/VirusForget Index page: Design Next page: Dev/boot user-sysmaint-split

user-sysmaint-split - Role-Based Boot Modes - USER Session / SYSMAINT Session (system maintenance) and their use cases. Through user-sysmaint-split as the new default feature in Kicksecure we introduce new different boot modes, aimed at improving security through role-based boot options.

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 "USER Session" for daily activities and "SYSMAINT Session" 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 opt-outs for users who prefer unrestricted admin mode.

These boot modes are generic and work for both hosts and VMs. This applies to Kicksecure and derivatives of Kicksecure, such as Whonix®.

user-sysmaint-split strenghtens Security-Driven Design:

  • Limited user accounts cannot access privilege escalation tools.
  • sysmaint session isolates system maintenance tasks from daily use.
  • Transitioning between modes enforces a stricter security model.

Development Goals[edit]

These goals guide the user/sysmaint isolation implementation:

Grub Default Boot Menu Entries[edit]

The default GRUB boot menu entries are:

  • PERSISTENT Mode | USER Session | daily activities
  • PERSISTENT Mode | SYSMAINT Session | maintenance tasks
  • LIVE Mode | USER Session | disposable use
  • LIVE Mode | SYSMAINT Session | maintenance testing

Use Cases for the Different Boot Modes[edit]

Common use cases tailored to the available boot modes:

  • PERSISTENT Mode | USER Session | daily activities
    • Ideal for browsing, email, chat, or running a pre-configured server.
    • read-only /usr, /etc. (Planned. Currently inability to elevate to root means that /usr and /etc are still read-write, but normal user accounts can't write anything there due to file permissions.)
    • read-write /home
    • Verified Boot: enabled. (Planned.)
  • PERSISTENT Mode | SYSMAINT Session | maintenance tasks: Allows running sudo apt install [package], editing /etc/apt/sources.list.d, and similar tasks. Reboot into USER session afterward.
    • read-write /usr, /etc, /home
    • Verified Boot: disabled
  • LIVE Mode | USER Session | disposable use: Similar to PERSISTENT Mode | USER Session | daily activities but without persistence.
  • LIVE Mode | SYSMAINT Session | maintenance testing: Similar to PERSISTENT Mode | SYSMAINT Session | maintenance tasks but without persistence.

Boot Modes Comparison Table[edit]

Feature PERSISTENT Mode USER Session LIVE Mode USER Session LIVE Mode SYSMAINT Session PERSISTENT Mode SYSMAINT Session
Description For daily activities such as browsing, email, chat, or running a pre-configured server. Similar to PERSISTENT Mode | USER Session | daily activities but without persistence. Similar to PERSISTENT Mode | SYSMAINT Session | maintenance tasks 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 session afterward.
File System Access: /usr, /etc No, read-only No, read-only No, read-only with ephemeral overlay Yes, read-write
File System Access: /home Yes, read-write No, read-only with ephemeral overlay No, read-only with ephemeral overlay Yes, read-write
Minimal Services No No Yes (sysmaint-boot.target) Yes (sysmaint-boot.target)
Verified Boot (planned) Yes, Enabled Yes, Enabled Yes, Enabled No, Disabled

Integration with Verified Boot[edit]

When booting into SYSMAINT Session, 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 Session, verified boot will be enabled for the purpose of improved security.

See also Verified Boot for account user but not for account sysmaint.

planned: Role-Based Boot Modes (user versus sysmaint session) has been implemented already. Verified boot is an additional security feature that is planned to be implemented later.

Opt-Out to Get the Same Behavior as Old Kicksecure[edit]

Users who wish "the old Kicksecure" "with unrestricted sudo for account user" back, who don't want the

  • LIVE Mode | SYSMAINT Session | maintenance testing
  • PERSISTENT Mode | SYSMAINT Session | maintenance tasks

boot options, could uninstall package user-sysmaint-split. It could be easily removed using dummy-dependency. (dummy-dependency is being used to avoid issues with meta package removal.)

This is documented on the unrestricted admin mode wiki page.

Design[edit]

Limited Environment[edit]

  • Question: Why log in to a limited environment instead of a full desktop?
  • Issues: A full desktop environment poses issues such as:
    • Increased attack surface: Systemd units running could provide attack surface (e.g., long-running file downloads/uploads).
    • Application exposure: The start menu could offer trivial access to high-risk applications web browsers, which could increase risk.

Implementation[edit]

No Access to Privilege Escalation Tools for Limited Accounts[edit]

There are conceptually two groups of accounts, privileged accounts and limited accounts.

Privileged accounts:

  • root
  • sysmaint

Limited accounts (examples):

  • user
  • nginx
  • mysql
  • sdwdate
  • ntp
  • etc.

These limited accounts are by default not a member of the groups root, sysmaint, or wheel.

Therefore limited Linux accounts such as account "user" 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 account 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 account root and group root. These can be read and execute by owner, group, and others (Public). (chmod 755) The following chmod-calc command to illustrate that.

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

user-sysmaint-split: Privilege Escalation Tools are owned by group sysmaint. others (Public) (which includes limited account user) no longer have read or execute rights. (The technical equivalent of: 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

Applications may no longer internally use passwordless sudo exceptions (e.g., /etc/sudoers.d). This is further detailed on the Dev/sudo page.

user group sudo membership[edit]

Should user-sysmaint-split postinst "run_once" sudo delgroup user sudo? No, not needed.

Limited account "user" can safely safely stay a member of group sudo by default thanks to No Access to Privilege Escalation Tools for Limited Accounts. This simplifies testing and the process of users wishing to go back to unrestricted admin mode.

Qubes Support[edit]

Package qubes-core-agent-passwordless-root will be no longer installed by default in Kicksecure for Qubes.

Qubes R4.2 and earlier[edit]

Exiting Templates: user-sysmaint-split is NOT installed by default for Kicksecure, Whonix-Gateway, or Whonix-Workstation.

New Templates: If user-sysmaint-split is installed into a template, both the template and AppVMs based on it will only boot into PERSISTENT mode | USER session. Other boot modes are inaccessible. For administrative actions, users can use a Qubes Root Console.

Qubes R4.3 and later[edit]

user-sysmaint-split is installed by default for Kicksecure and Whonix-Workstation. It will NOT be installed on Whonix-Gateway by default.

By default, Qubes Templates with user-sysmaint-split installed will boot into PERSISTENT mode - SYSMAINT session. Administrative tasks can be done freely in this environment. AppVMs based on these templates will boot into PERSISTENT mode | USER session by default. Users can configure this behavior as they desire by using Qube Manager to change VM boot modes. LIVE mode | USER session and LIVE mode | SYSMAINT session are both currently unsupported, but may be supported later.

Qubes Security Known Issue[edit]

Remaining Issues[edit]

Fast User Switching[edit]

sysmaint - System Maintenance User documentation chapter Fast User Switching explains, that

It is not possible to switch from account user to sysmaint using:

  • Start Menu → logout
  • Start Menu → switch user

This is a security feature. This is to mitigate login spoofing attacks and to prevent sudo password sniffing.

The best-case potentially realistic scenario for fast user switching from account user to sysmaint - in theory - would be:

1. Learn about SysRq.

2. Logout with "save session" as user. This means saving the session to disk and allowing it to be resumed, but no processes must continue to run.

3. Use Alt + SysRq + k (Secure Access Key).

4. Login into sysmaint.

5. Perform system administration.

6. Logout of sysmaint.

7. Use Alt + SysRq + k (optional, just to establish the habit).

8. Resume the user session.

However, even using SysRq to switch from account user to sysmaint or vice versa would be less secure, because when booting into sysmaint mode (sysmaint-boot.target), only a minimal number of services are started.

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. Booting a server into sysmaint mode with minimal services (such as SSH, but not web servers, etc.) might not be practical due to downtimes.

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:

Usability[edit]

  • Terminal application risks:
    • Ability to run applications like Firefox from the terminal emulator in sysmaint mode.
  • Documentation access in sysmaint mode:
    • Why read documentation in sysmaint mode?
      • Necessary for complex system maintenance tasks.
      • For online searches or resolving issues.
      • Using AI assistants or posting on forums.
  • Offline documentation:
    • Offline documentation is helpful but insufficient since it often links extensively to upstream resources.
    • Users are encouraged to refer to online documentation whenever possible (upstream resources).
  • Alternatives:
    • Separate computer: Ideally, such tasks should be performed on a separate computer.
    • Virtual machine (VM): A less ideal but safer option is to use a VM for such tasks.
      • If Verified Boot and A/B updates are implemented, a sandbox feature could be designed to boot the host OS itself in a VM using immutable images, enhancing safety.

Rejected Alternative Implementations[edit]

  • Chroot-based solutions:
    • Complex and messy: Involves managing two systems for upgrades.
    • Disk mounts challenges: Bootloader upgrades, encryption, LVM, RAID, and other configurations must be handled correctly.
    • System updates: Maintaining two systems for updates is difficult.
  • Single user mode (kernel parameter single):
    • Does not allow login to graphical targets.
  • Start menu restrictions:
    • Hide applications like Firefox when booting into sysmaint mode.
    • Implementation difficulty: Desktop environment-specific changes are required.
  • Systray indicator:
    • A system tray icon could display a sysmaint symbol to indicate the current mode.
  • Warning popups:
    • When starting Firefox in sysmaint mode, a popup could warn users to avoid browsing the internet unless absolutely necessary.

Boot Menu Names and Ordering[edit]

Mode First Ordering[edit]

Initial implementation. 

PERSISTENT Mode | USER Session | For daily activities
LIVE Mode | USER Session | For disposable use
PERSISTENT Mode | SYSMAINT Session | For maintenance tasks
LIVE Mode | SYSMAINT Session | For maintenance testing
REMOVE sysmaint-user-split | Enable unrestricted admin mode

Session First Ordering[edit]

Potential future implementation based on user feedback. 

USER Session | PERSISTENT Mode | For daily activities
USER Session | LIVE Mode | For disposable use
SYSMAINT Session | PERSISTENT Mode | For maintenance tasks
SYSMAINT Session | LIVE Mode | For maintenance testing
REMOVE sysmaint-user-split | Enable unrestricted admin mode

/etc/grub.d[edit]

ls -1 /etc/grub.d 

00_header
05_debian_theme
10_00_linux_dist
10_10_linux_sysmaint
10_20_linux_live
10_30_linux_remove_sysmaint
10_50_linux_dist_advanced
10_55_linux_sysmaint_advanced
10_60_linux_live_advanced
10_65_linux_remove_sysmaint_advanced
20_linux_xen
30_os-prober
30_uefi-firmware
35_fwupd
40_custom
41_custom
45_debugging
README

Simplified. Relevant files only. Left out "advanced" for simplicity. 

10_00_linux_dist
10_10_linux_sysmaint
10_20_linux_live
10_30_linux_remove_sysmaint

10_00_linux_dist            -> PERSISTENT Mode - User Session
10_10_linux_sysmaint        -> PERSISTENT Mode - SYSMAINT Session (executes /etc/grub.d/10_00_linux_dist + options)
10_20_linux_live            -> LIVE Mode - USER Session (executes /etc/grub.d/10_20_linux_live + options)
                            -> LIVE Mode - SYSMAINT Session (executes /etc/grub.d/10_10_linux_sysmaint + options)

Boot Modes Considered Too Unimportant to Be Added to GRUB Default Boot Menu[edit]

DIY Methods to Include Other Entries in the GRUB Boot Menu

A Files in the /etc/grub.d/ folder could add 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.

Wiki[edit]

BootEntries[edit]

Template:BootEntries

Code Result
{{BootEntries|key=userpers}} PERSISTENT Mode | USER Session | daily activities
{{BootEntries|key=userlive}} LIVE Mode | USER Session | disposable use
{{BootEntries|key=userpersad}} ADVANCED options for PERSISTENT Mode | USER Session | More options
{{BootEntries|key=syspers}} PERSISTENT Mode | SYSMAINT Session | maintenance tasks
{{BootEntries|key=syslive}} LIVE Mode | SYSMAINT Session | maintenance testing
{{BootEntries|key=sysremove}} REMOVE sysmaint-user-split | enable unrestricted admin mode

Prior Versions[edit]

Older concept version still containing "SUPERADMIN" and "SECUREADMIN".archive.org iconarchive.today icon

Tickets[edit]

Related[edit]

Attribution[edit]

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: Providing secure user accessarchive.org iconarchive.today icon


Design Previous page: Dev/VirusForget Index page: Design Next page: Dev/boot

Notification image
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!

Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/user-sysmaint-split&oldid=97051"