Skip to main content

How to limit container privilege with socket activation

Using socket activation with the --network=none option limits an intruder's ability to use a compromised container as a starting point for attacks on other devices.
Image
Colorful plant garden pots

Anytime you have a network service that is accessible to the public internet, you must try to minimize the potential for damage if it is compromised. One way is to run a network daemon with as few privileges as possible. Assuming the compromise is not caused by a kernel bug, an intruder's access will be limited to the privileges granted to the running network daemon.

There's a new feature in Podman that lets you run network daemons with restricted network access. Since version 3.4.0, Podman supports socket activation in containers, meaning that you can pass a socket-activated socket to your container. It's possible for a container to use a socket-activated socket even when the network is disabled (that is, when the option --network=none is passed to podman run).

[ Download now: Podman basics cheat sheet ]

Not all software daemons support socket activation but it's becoming increasingly popular. For instance, Apache HTTP server, MariaDB, DBUS, PipeWire, Gunicorn, and CUPS all have socket activation support.

A note on SELinux: If your computer runs SELinux, you must have container-selinux 2.183.0 or newer installed to run these examples.

An echo server example

You can try out socket-activate-echo, a simple echo server container that supports socket activation.

First, create a container named echo:

$ podman create \
--rm --name echo \
--network=none \
ghcr.io/eriksjolund/socket-activate-echo

Next, generate a systemd service unit:

$ mkdir -p ~/.config/systemd/user

$ podman generate systemd --name \
--new echo > ~/.config/systemd/user/echo.service

A socket-activated service also requires a systemd socket unit, so create the file ~/.config/systemd/user/echo.socket. In it, define the sockets that the container uses:

[Unit]
Description=echo server

[Socket]
ListenStream=127.0.0.1:3000
ListenDatagram=127.0.0.1:3000
ListenStream=[::1]:3000
ListenDatagram=[::1]:3000
ListenStream=%h/echo_stream_sock

[Install]
WantedBy=sockets.target

The %h entity is a systemd specifier that expands to the user's home directory.

After editing the unit files, reload the systemd configuration:

$ systemctl --user daemon-reload

Next, start the socket unit:

$ systemctl --user start echo.socket

[ Download now: Advanced Linux commands cheat sheet. ]

Test the echo server with the program socat:

$ echo hello | socat - tcp4:127.0.0.1:3000
hello

$ echo hello | socat - tcp6:[::1]:3000
hello

$ echo hello | socat - udp4:127.0.0.1:3000
hello

$ echo hello | socat - udp6:[::1]:3000
hello

$ echo hello | socat - unix:$HOME/echo_stream_sock
hello

The echo server works as expected. It replies hello after receiving the text hello.

Controlling connections

If the echo server is compromised due to a vulnerability, the container might be used to launch attacks against other PCs or devices on the network. However, consider that an echo server only needs to accept incoming connections on the socket-activated socket it inherits. It does not need the ability to establish outgoing connections.

Fortunately, the command-line option –-network=none provides these kinds of restrictions.

$ grep -B8 -- --network=none \
~/.config/systemd/user/echo.service
ExecStart=/usr/bin/podman run \
--cidfile=%t/%n.ctr-id \
--cgroups=no-conmon \
--rm \
--sdnotify=conmon \
-d \
--replace \
--name echo \
--network=none ghcr.io/eriksjolund/socket-activate-echo

[ Improve your skills managing and using SELinux with this helpful guide. ]

Assume an intruder has shell access in the container. The situation can be simulated by executing commands with podman exec:

$ podman exec -ti \
echo /usr/sbin/ip -brief addr
lo UNKNOWN 127.0.0.1/8 ::1/128

Only the loopback interface is available:

$ podman exec -ti \
echo /usr/bin/curl https://podman.io
curl: (6) Could not resolve host: podman.io

The curl command is not able to download a web page. The network interface tap0 that rootless Podman normally uses to access the internet is unavailable.

If I instead remove the option --network=none, reload the systemd daemon, restart the service, and run the same commands, I see that the network interface tap0 is available:

$ podman exec -ti \
echo /usr/sbin/ip -brief addr
lo UNKNOWN 127.0.0.1/8 ::1/128
tap0 UNKNOWN 10.0.2.100/24 fd00::9847:3aff:fe5d:97ea/64 fe80::9847:3aff:fe5d:97ea/64

Now curl can download the web page:

$ podman exec -ti \
echo /usr/bin/curl https://podman.io | head -2
<!doctype html>
<html lang="en-US">

Socket activation

Using socket activation together with the option --network=none for containerized network daemons is a new way to improve security in Podman. It limits the possibilities for an intruder to use a compromised container as a starting point for attacks on other PCs.

My follow-up article takes this idea one step further by also restricting internet access for Podman and its helper programs such as conmon and the OCI runtime. The socket activation tutorial provides more information about socket activation support in Podman.

Check out these related articles on Enable Sysadmin

Topics:   Podman   Security   Containers  
Author’s photo

Erik Sjölund

Erik Sjölund enjoys learning and discovering new things, especially within container technologies. He holds a master's degree in Engineering Physics and has worked as a Linux sysadmin and software developer, especially in the field of life sciences. More about me

Red Hat Summit 2022: On Demand

Get the latest on Ansible, Red Hat Enterprise Linux, OpenShift, and more from our virtual event on demand.

Related Content

OUR BEST CONTENT, DELIVERED TO YOUR INBOX