Security

Security

MiniOS security controls are designed around the live system: temporary sessions, persistent sessions, portable media, and boot-time configuration. MiniOS Installer can also perform a native conversion. The resulting system keeps the selected desktop environment and MiniOS visual identity, but the live-specific MiniOS software is removed, so secure and maintain it with the normal Debian tools rather than treating it as another live mode. Protect the running session, persistent data, boot media, and any configuration that is applied at startup.

Start with trusted media

Download MiniOS from an official source and verify the ISO before writing it. Follow Verifying downloads and compare the result before booting or installing. Verification detects a damaged or substituted download; it does not prove that an already modified USB device is safe.

Keep the USB device under physical control. Firmware passwords and restricted boot order can reduce casual unauthorized booting, but do not encrypt files on the device. Secure Boot may provide additional boot-chain protection on images and hardware that support it; check the actual release and firmware behavior rather than assuming support.

Replace default credentials

An uncustomized MiniOS live image uses the published credentials live / evil and root / toor, with automatic login and passwordless administrative access in its convenience-oriented configuration. Anyone who can reach the system may be able to use those credentials, especially if SSH is active.

Before joining an untrusted network:

1. Set unique user and root passwords in MiniOS Configurator.
2. Select an appropriate security profile and review every populated control.
3. Disable SSH and XRDP unless remote access is required.
4. Reboot into a new session when changing one-shot account or security settings, then verify the resulting login and privilege behavior.

The Configurator stores encrypted password hashes rather than plaintext passwords. If changing an already created persistent account, use passwd for the current user and sudo passwd root for root. After native conversion, use the normal Debian account-management tools.

Use Configurator security controls

MiniOS Configurator provides three profiles. A profile fills concrete settings; the profile name itself is not saved as a runtime configuration key, and each setting remains independently editable.

Profile	Main behavior
convenient	Autologin-compatible, passwordless sudo and PolicyKit, root and password SSH allowed, relaxed XRDP/X11/lock screen, password hints shown.
balanced	No autologin, password-required sudo and PolicyKit, SSH root login denied but password SSH allowed, hardened XRDP/X11/lock screen.
strict	No autologin, password-required sudo and PolicyKit, SSH root and password login denied, XRDP disabled, hardened X11/lock screen, password hints hidden.

The installer defaults differ by deployment mode: live installations favor convenient, while native conversion starts from balanced. The native setting is applied during conversion; after installation, use the normal Debian security configuration. These are defaults, not recommendations for every threat model.

The same settings are available as documented configuration keys, including LIVE_SUDO_MODE, LIVE_POLKIT_MODE, LIVE_SSH_PERMIT_ROOT_LOGIN, LIVE_SSH_PASSWORD_AUTHENTICATION, LIVE_XRDP_MODE, LIVE_X11_MODE, LIVE_ISSUE_PASSWORD_HINTS, and LIVE_LOCKSCREEN_MODE. Prefer these keys or the Configurator over editing generated sudoers, PolicyKit, display-manager, or SSH files. See Configuration file. For save behavior and setting applicability, see MiniOS Configurator.

Account creation, passwords, LIVE_CONFIG_NOROOT, and the security posture are one-shot settings used when a new session is created. The Configurator shows applicability for each control. Reconfigurable settings such as services are applied after reboot.

Secure remote access

SSH may be enabled in a MiniOS image for recovery use. On a network where other users are not trusted, assume the published default credentials are exposed until you have confirmed otherwise.

• If SSH is unnecessary, add ssh to DISABLE_SERVICES in Configurator and remove it from ENABLE_SERVICES if present.
• If SSH is required, deny root login with LIVE_SSH_PERMIT_ROOT_LOGIN=false.
• Prefer key authentication. Confirm key login in a separate connection before setting LIVE_SSH_PASSWORD_AUTHENTICATION=false.
• Restrict inbound access with the network firewall or router, and do not expose a portable recovery system directly to the Internet.
• Review XRDP separately. The strict profile disables it; the balanced profile hardens it but does not necessarily disable its service.

Boot parameters can override configuration-file values. Inspect unexpected service behavior against Boot parameters.

Encrypt persistent data

Unencrypted native, DynFileFS, DynBlk, VMDK, raw, and SquashFS persistence can be read by someone who obtains the device. MiniOS can layer LUKS2 over Raw, DynFileFS, DynBlk, or VMDK. LUKS2 remains an encryption layer, not a separate session mode. For boot-time creation select it with perchencrypt=luks; existing sessions obtain their encryption state from session metadata rather than from a later command-line override.

The encryption boundary differs by backend. Raw encrypts the logical block image inside changes.img; DynFileFS encrypts the exposed virtual.dat; DynBlk and VMDK encrypt the block device exposed by the DynBlk driver. Session metadata, boot files, backend metadata and VMDK descriptors outside the encrypted block device, and unrelated files on the medium remain visible. DynBlk backend compression is disabled when LUKS2 is selected; VMDK does not provide backend compression.

Boot-time creation asks for the passphrase twice in the initrd. When Installer pre-creates an encrypted session on the target, its wizard collects and confirms the passphrase and passes it to minios-session through standard input. It is not stored in configuration, logs, or process arguments. Existing encrypted sessions ask for their passphrase at boot; three rejected unlock attempts stop the boot path rather than falling back to plaintext, another backend, or an in-memory replacement under the same persistence request.

The MiniOS LUKS2 persistence layer protects filesystem contents while the mapper is closed. It does not protect data after unlock, the unencrypted boot files, copied files outside the encrypted backend, or a native root filesystem. Layered persistence encryption is not native root encryption. Logical exports contain decrypted session files, so protect backup archives separately. Use a strong passphrase and keep a tested backup.

Temporary cache or journal storage is a write-reduction choice, not encryption. With durable persistence, MiniOS keeps minios-boot and live-config diagnostics on the session store even when LIVE_LOG_STORAGE=volatile. For durable SquashFS these files are outside changes.sb, under the session's boot-logs/ directory. With perchtoram, the session and its diagnostics are memory-backed; persistence requires a successful save to storage. An unencrypted backing device exposes its logs along with its other files. LIVE_CONFIG_DEBUG=true additionally enables detailed traces and copies of user-account merge inputs; keep debug disabled in ordinary use and review those logs before sharing them. See Performance.

See MiniOS Installer and Session management.

Apply updates deliberately

Refresh package metadata and install Debian security updates in persistent live sessions with the normal APT workflow when that is appropriate. APT changes in a fresh live session disappear at reboot. Base SquashFS modules are read-only, so replacing the ISO or modules with a newer trusted MiniOS release is often the cleanest way to update the base live system. After native conversion, package security maintenance is simply the ordinary Debian APT workflow for that installed system.

See Software updates for the separate APT, module, image, and kernel workflows.

Before a large update:

• Back up important files and persistent sessions.
• Confirm enough free space is available.
• Avoid interrupting writes or powering off the device.
• Reboot and verify the updated system before discarding the previous known-good media or session.

Treat hooks and preseeding as code execution

The hooks boot option and live-config hooks can execute files from the root filesystem, boot medium, or a URL. Remote hooks, modified media hooks, and unreviewed preseeds can run with system privileges. Use only reviewed files from a trusted source, prefer authenticated distribution, and avoid remote hooks on untrusted networks. See live-config for the execution order and supported locations.

Back up and retire media safely

Persistence is not a backup. Keep a separate copy of user files and export or copy sessions while they are healthy. Test restoration on different media. Shut down cleanly before removing writable storage, and keep free space for session metadata and filesystem operation.

Before disposing of a device, securely erase it according to the storage technology and sensitivity of the data. Deleting files or reformatting alone may not make old data unrecoverable.