Users, Groups & Services

This page covers day-to-day administration of user accounts, groups, and system services on InterGenOS. The defaults described here reflect the design philosophy of the system: a machine you understand, can modify, and can trust.

InterGenOS 1.0-dev (build id v1.0-dev1) ships GNOME 49 on Wayland as its desktop, with systemd as the init system and service manager.

Users and Groups

InterGenOS uses the standard Linux user and group model. Accounts live in /etc/passwd, groups in /etc/group, and shadowed password hashes in /etc/shadow. The usual coreutils and shadow-suite tools apply.

Creating and managing accounts

# Add a new user with a home directory and login shell
useradd -m -s /bin/bash alice

# Set or change a password
passwd alice

# Add a user to a supplementary group
usermod -aG <group> alice

# Lock or unlock an account
usermod -L alice
usermod -U alice

# Remove a user (and optionally their home directory with -r)
userdel -r alice

Group management follows the same conventions:

groupadd developers      # create a group
gpasswd -a alice developers   # add a member
groupdel developers      # remove an empty group

Account policy

InterGenOS does not ship services or databases with blank or default admin passwords. Initial credentials are randomly generated or set up manually during installation, so there is no well-known account to compromise on a fresh system. When you create accounts afterward, you choose the credentials and the policy.

On a default install, password quality is enforced by pam_pwquality: a password must be at least 12 characters and include at least one uppercase letter, one lowercase letter, one digit, and one other character, with no more than three identical characters in a row — and the rule applies to root as well. Repeated failed logins are rate-limited by pam_faillock. Passwords do not expire on a timer by default, because forced rotation tends to push people toward weaker, more predictable choices; you are free to set an expiry policy if your environment requires one. The first account Forge creates is added to the administrative wheel group (which grants sudo) along with the audio, video, input, cdrom, and lpadmin groups for desktop hardware and printing.

The first user account is created during installation by Forge, the InterGenOS installer. See the Forge installer guide for how the initial account and its administrative access are set up.

Privilege escalation

Administrative actions are performed with sudo rather than by logging in as root directly. InterGenOS does not ship doas. Administrative users are granted their elevated access by membership in the wheel group.

Services and the Init System

InterGenOS uses systemd to manage services, sockets, timers, and the boot sequence. Administration uses the standard systemctl and journalctl tooling.

Managing services

systemctl status <unit>      # inspect a service
systemctl start <unit>       # start now
systemctl stop <unit>        # stop now
systemctl restart <unit>     # restart
systemctl enable <unit>      # start at boot
systemctl disable <unit>     # do not start at boot
systemctl enable --now <unit>  # enable and start in one step

Reading logs

journalctl -u <unit>         # logs for one unit
journalctl -b                # logs since the current boot
journalctl -f                # follow new log entries live

Service Hardening Defaults

InterGenOS does not rely on post-installation hardening scripts. System services are sandboxed from the moment the system boots, to minimize the blast radius of a potential compromise. Every system daemon runs under extensive systemd isolation directives, and InterGenOS additionally ships AppArmor profiles for selected daemons. Profiles are loaded with apparmor_parser (/usr/sbin/apparmor_parser). The default AppArmor mode is enforce, with a few shipped profiles intentionally written in complain (learning) mode — currently intergen-mcp and pkm — which graduate to enforce per-profile as confidence builds.

The baseline systemd directives applied across system daemons include:

Directive	Effect
`NoNewPrivileges=true`	A service and its children cannot gain new privileges
`ProtectSystem=strict`	The entire filesystem hierarchy is read-only to the service
`ProtectHome=true`	User home directories are inaccessible
`PrivateTmp=true`	The service gets a private, isolated `/tmp`
`PrivateDevices=true`	Only a minimal, virtual `/dev` is exposed
`ProtectKernelTunables=true`	`/proc` and `/sys` kernel tunables are read-only
`ProtectKernelModules=true`	Module load/unload is denied
`ProtectKernelLogs=true`	The kernel ring buffer is inaccessible
`ProtectControlGroups=true`	The cgroup hierarchy is read-only
`ProtectHostname=true`	The hostname cannot be changed
`ProtectClock=true`	The system clock cannot be changed
`ProtectProc=invisible`	Other processes are hidden in `/proc`
`RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6`	Only these socket families are permitted
`RestrictNamespaces=true`	Creating new namespaces is denied
`RestrictRealtime=true`	Realtime scheduling is denied
`RestrictSUIDSGID=true`	Creating SUID/SGID files is denied
`LockPersonality=true`	The execution-domain personality is locked
`MemoryDenyWriteExecute=true`	Writable-and-executable memory is denied (a package whose runtime needs a JIT can set this to `false` in its own unit, as PostgreSQL does for its LLVM JIT)
`RemoveIPC=true`	IPC objects are cleaned up when the service stops
`SystemCallArchitectures=native`	Only native-architecture syscalls are allowed
`SystemCallFilter=@system-service`	A baseline syscall allowlist is enforced
`SystemCallFilter=~@privileged @resources @mount @swap @reboot`	Privileged and dangerous syscall groups are denied

You can inspect the effective sandbox of any running service with:

systemd-analyze security <unit>

Safe network binds

Any server package shipped by InterGenOS binds exclusively to localhost (127.0.0.1) by default. Services never listen on public interfaces unless you deliberately edit their configuration to allow it. If you intend to expose a service, that is a conscious change you make, not a default you have to discover and undo. See Network security for the broader posture.

Overriding the defaults

These directives are defaults, not a cage. Because you control your own machine, you can relax a directive for a specific service with a drop-in override:

systemctl edit <unit>

This creates a drop-in under /etc/systemd/system/<unit>.d/ that layers on top of the shipped unit without modifying it. Reload and restart to apply:

systemctl daemon-reload
systemctl restart <unit>

For the rationale behind these controls and how they fit the wider security model, see Sandboxing and mandatory access control and the Hardening baseline.

What Runs By Default

InterGenOS keeps the running surface small. It collects zero telemetry, no analytics, and no crash or usage reports, so there are no background phone-home services to disable. The system will not update software behind your back; updates happen only when you explicitly run the package manager. There are no opt-out privacy toggles to hunt for, because the data never leaves to begin with.

Two InterGenOS services are worth knowing about because they are part of what makes the system distinctive:

InterGen is a tiered, hardware-detected, offline-first local assistant built on Qwen models, with zero telemetry. It runs locally and selects a model tier appropriate to your hardware. When a query exceeds local capability, the optional “Phone-A-Friend” (Frontier/Cloud Escalation) path can hand off to a remote model, but only when you invoke it.
InterGen Sentinel is a pluggable security scanner. Its default backends are Local-Rules and Local-Qwen, both running on your machine. Cloud providers are available strictly opt-in — currently Claude (Anthropic), Gemini (Google), Copilot (Microsoft), ChatGPT (OpenAI), Grok (xAI), and DeepSeek.

Neither sends anything off the machine unless you explicitly opt into a cloud backend.

InterGenOS Wiki