user-sysmaint-split

From Kicksecure
< Dev
Jump to navigation Jump to search

user-sysmaint-split - Role-Based Boot Modes - Persistent User / Live user / Persistent sysmaint (system maintenance) and their use cases.

Security-Driven Design:

  • Limited users can't access privilege escalation tools.
  • sysmaint mode isolates system maintenance tasks from daily use.
  • Transitioning between modes enforces a stricter security model.

In development.

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 unrestricted admin mode.

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:

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 running sudo 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

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
Minimal Services No No Yes (sysmaint-boot.target)
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.

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 is being used to avoid issues with meta package removal.)

This is documented on the unrestricted admin mode wiki page.

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.

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 access to applications like Firefox, 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:

  • user
  • nginx
  • mysql
  • sdwdate
  • ntp
  • Not a member of groups root, sudo, or wheel.
  • etc.

Limited Linux accounts such as accounts "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. (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

user-sysmaint-split: Privilege Escalation Tools are owned by group sysmaint. others (which includes limited account user) 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.

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.

For administrative actions, users can use a Qubes Root Console.

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 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 SysRq + k (Secure Access Key).

4. Login into sysmaint.

5. Perform system administration.

6. Logout of sysmaint.

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

8. Resume the user session.

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.

Prior Versions[edit]

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

Tickets[edit]

Related[edit]

Attribution[edit]

Kicksecure is an Implementation of the Securing Debian Manual. This chapter has been inspired by: Securing Debian Manualarchive.org, chapter Mounting partitions the right wayarchive.org


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 12 year success story and maybe DONATE!

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