Account and Access Hardening

Introduction

A default Torizon OS development image ships a torizon user with password login, membership of the sudo and docker groups, and convenient remote shell access. Those defaults make development and debugging smooth. For production, you usually want a tighter account policy: who can log in, how they authenticate, and what a login session can do.

Membership of the docker group is effectively equivalent to root: a torizon session with Docker access can start a container that bind-mounts the host /. Masking SSH removes the network listener, but it does not change what a console session or a Remote Access session can do once logged in. Account hardening therefore matters independently of the network work in Network Hardening.

OSTree keeps /usr immutable, but accounts, group membership, and sudo policy live in the writable merge layer under /etc. This article covers the most common account and access changes when you move from a development device to a production-ready image.

This article is part of the Production Hardening Checklist, which also explains how to persist these changes across a fleet.

This article complies with the Typographic Conventions for the Toradex Documentation.

Recommended Baseline

1. Mask sshd.socket and use Torizon Remote Access when you need a network shell, as described in Network Hardening.
2. Lock the torizon password, unless you have a deliberate console debug login requirement. See the trade-offs below.
3. Remove torizon from the docker group on production images.
4. Audit sudo policy, with no NOPASSWD: ALL rule, and prefer minimal or no sudo access in production.
5. Keep root locked, and do not set a root password for convenience.
6. Remove leftover human accounts created during bring-up.

Locking the torizon Password

The stock image ships the torizon user with a password. That is convenient during development. For production, locking the password is usually appropriate wherever a password login path still exists, whether that is SSH, a serial login prompt, or a virtual console.

# sudo passwd -l torizon

Verify the result. The command reports L for a locked account:

# passwd -S torizon

Locking with passwd -l prepends ! to the stored hash, so PAM password authentication fails. SSH key authentication, and any other mechanism that does not use the account password, can still work depending on how you configure access.

The trade-offs are:

Locking the password	Keeping a password
Stops password login over SSH, the serial console, and the virtual terminals	Requires you to treat the password as a secret that is strong, unique, and rotated. See Enforcing Strong Passwords.
Suits devices that use Remote Access or keys only, with consoles masked as described in Boot and Hardware Hardening	Some products must keep a serial debug login for factory work, field service, or bring-up. Locking the password then locks operators out of that path unless you provide another authentication method on the console.
Removes a shared password as a login factor	Combining a password with a listening SSH socket is usually not appropriate for production, so mask sshd.socket even when the console stays password-based

In practice, lock the password when interactive access is through Remote Access or keys and production consoles are disabled. If you deliberately keep a serial login prompt for debugging, you may need to keep a password, or provide another console authentication method. In that case harden everything around it: no standing SSH listener, no docker group membership, a strong password policy, and a recorded assumption about who can physically reach the device.

Removing torizon from the docker Group

Membership of the docker group grants access to /var/run/docker.sock. That API can start privileged containers and bind-mount the host filesystem, so treat docker group membership as equivalent to passwordless sudo when you decide who should have it on a production image.

# sudo gpasswd -d torizon docker

Verify the result. The output should no longer list docker:

# groups torizon

The trade-offs are:

Removing docker group membership	Leaving torizon in the docker group
A logged-in torizon session can no longer manage containers through the socket alone	Any successful login as torizon retains root-equivalent Docker access
Operators and automation need another route to run containers: root through a narrow sudo rule, a systemd unit that runs Compose, or a cloud deployment, rather than an interactive user in the group	Convenient for lab development; usually broader than you want for production interactive logins
Remote Access sessions as torizon have a narrower privilege set	Combines poorly with password authentication or an exposed SSH listener

sudo Policy

The stock file /etc/sudoers.d/50-torizon grants %sudo ALL=(ALL) ALL, with a password required. That is broad, but still better than a NOPASSWD rule. Any NOPASSWD rule that can start a shell, or invoke docker, is root access without a password.

Inspect the policy as root:

# sudo visudo -c
# sudo grep -RIn -- '.' /etc/sudoers /etc/sudoers.d/

Never ship NOPASSWD: ALL. Where sudo access remains necessary, prefer a narrow list of permitted commands over %sudo ALL=(ALL) ALL.

The root Account

Interactive root login is usually unnecessary on Torizon OS. The shadow entry for root by default uses *, which disables password authentication for the account. Leave it that way, and do not set a root password for convenience.

Unused and Extra Accounts

The interactive human account on stock Torizon OS is torizon, alongside a locked root. After bring-up or customization, audit for any additional login-capable users you did not intentionally add, such as leftover test accounts, vendor provisioning users, or copies of torizon with a shell.

Base accounts live under /usr/lib/ because of the OSTree layout, while local additions live under /etc, so check both:

# cat /etc/passwd /usr/lib/passwd

Lock or remove any unexpected human account:

# sudo passwd -l someuser

Do not remove system accounts

System users with a nologin or false shell, such as avahi, sshd, and messagebus, are normal and expected. Removing them breaks the services that depend on them. Use userdel only on accounts you can positively identify as unwanted.

Verifying After Deployment

After the hardened image is deployed, confirm that the policy actually took effect:

# passwd -S torizon
# groups torizon
# ls -l /var/run/docker.sock