ShieldedBytes

Why Rootless Containers Still Need Guardrails

Running containers as a non‑root user is a solid first line of defense, but it’s not a silver bullet. A mis‑configured image, a vulnerable app, or a simple oversight can still let a container touch /etc, /var, or even your own home directory. This post walks through the hardening steps that keep file writes strictly inside a rootless runtime’s writable layer.

1. The Rootless Model in 2026

Rootless mode is all about user namespaces. The container’s root (uid 0) gets mapped to a non‑root UID on the host, and the kernel enforces that the process can only see files that belong to that UID. The catch is that the mapping is per‑process, not per‑filesystem. If a container mounts a host directory or a volume, the process inside can write to it unless the mount options explicitly deny it.

Why split DNS between interfaces?

When a machine plugs into a VPN it usually needs to look up hostnames that live only inside that tunnel.
If you let the whole system talk to the same nameserver, two things can go wrong:

• The VPN’s DNS might not be reachable until the tunnel is up, so internal lookups fail.
• Public resolvers get handed internal queries, leaking sensitive names to the outside world.

Binding a dedicated DNS server to the VPN link keeps the resolver stack tidy, cuts the attack surface, and stops accidental leaks.

A One‑Command Escape from Emergency Mode

When a typo in /etc/fstab stops the root filesystem from mounting, Ubuntu 24.04 drops straight into emergency mode. You get a read‑only root shell, but that’s not useful because you can’t edit the offending line—root is already mounted read‑only. The usual fix is to reboot, pull out a live USB, and patch the file from there.
There’s a much quicker way that keeps you on the same machine, preserves the state, and lets you fix the problem in place.

ACLs for log‑only access

When you need a user to read system logs but you don’t want to give them sudo or pull them into a privileged group, POSIX ACLs are the cleanest way to do it.
They let you hand out read rights on a per‑file or per‑directory basis, and you can set defaults so that every new file inherits the same restrictions.

A backup account that pulls logs to an off‑site archive but never touches the live system is the classic case. ACLs keep the principle of least privilege intact while still letting the job run unattended.

Rootless Podman on a Raspberry Pi – Solving the “Cannot Bind Mount /home/user/data” Permission Issue
The Raspberry Pi has become a favorite platform for home‑lab enthusiasts, and Podman’s rootless mode lets you run containers without granting the container process full system privileges.
On a Pi running Raspberry OS Bookworm (Debian 12), a common stumbling block is the error

Error: cannot bind mount /home/user/data: permission denied

when you try to persist data with -v /home/user/data:/data.
Below is a step‑by‑step guide that explains why the error happens, how to fix it, and what security trade‑offs you should be aware of.

Why you need it

Syslog is the first place you look when something goes wrong. In a busy server or a home lab, the same message can appear thousands of times a day. Knowing which lines dominate the log helps spot misconfigurations, repeated failures, or malicious activity that repeats silently. A quick frequency count is a low‑overhead sanity check that can turn a noisy log into a focused list of suspects.

Why Docker logs can eat a NAS

A home NAS is usually a single‑disk or a small RAID array.
When you run several containers—media servers, databases, CI runners—each one writes a JSON log file under /var/lib/docker/containers/<id>/<id>-json.log.
If you leave the default json-file driver untouched, those files grow indefinitely.
On a 1 TB NAS, a handful of containers can fill the drive in weeks, forcing you to delete data or upgrade hardware.

Why firewalld blocks HTTP even when port 80 is open

I’ve run Fedora, CentOS, and RHEL for the past two decades, and firewalld is the default manager on those distros. It hides the nitty‑gritty nftables/iptables behind zones, services, and ports. That abstraction is handy, but it can also mask a subtle mismatch that ends up dropping HTTP traffic even though you’ve “opened” port 80. The culprit is almost always a services vs. ports trap.

Why ACLs instead of changing ownership?

When a web server runs as www-data and the dev squad needs to touch files in /var/www/html, the quick fix is usually chgrp the directory and slap a write bit on the group. That swaps the group ownership, which can trip up services that expect the original group or automated deploy scripts that hard‑code the owner. ACLs let you hand out the right permissions without touching the classic ownership columns.

Why a single auditd rule is better than scattered syslog entries

When you run sudo, you’re stepping into privileged territory. Most distros ship a sudo wrapper that dumps a message into syslog. That message can be noisy, hard to sift through, and it doesn’t survive a clean‑up or a reboot. A dedicated auditd rule, on the other hand, captures every sudo invocation in a structured, tamper‑evident format. Couple that with a tiny logrotate config, and you get a reliable audit trail that sticks around long after the machine has been rebooted or the disk wiped.