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.
저자 소개
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.
유사한 검색 결과
From incident responder to security steward: My journey to understanding Red Hat's open approach to vulnerability management
Deploy Confidential Computing on AWS Nitro Enclaves with Red Hat Enterprise Linux
What Is Product Security? | Compiler
Technically Speaking | Security for the AI supply chain
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
가상화
온프레미스와 클라우드 환경에서 워크로드를 유연하게 운영하기 위한 엔터프라이즈 가상화의 미래