Docker Inc. was the first company to give the users an easy-to-use way to isolate processes through Linux namespaces, cgroups etc.

But its implementation came with a lot to desire when it comes to security and stability.

docker runs as a daemon with root access, which means that the daemon is a single point of failure and the security has been applied as an add-on.

 

Since docker was released other companies has implemented similar kind of easy-to-use way of isolating processes, but have taken the lessons learned from Docker Inc.s' implementation and done more stable and secure implementations.

 

The most common one being podman. Podman is created as a drop-in replacement for docker.

You can create an alias "docker" that points to the podman binary and most things will work right out of the box.

Unlike docker, podman doesn't use a daemon and can run completely rootless.

 

By giving the users of unraid the ability to use rootless podman instead of docker, you will give the users a more secure and stable platform than the alternative while still giving use the ability to run containerized workloads.

Given the small heart attack I just had with leaky-vessel vulnerabilities, podman might be a really smort alternative. 

 

URL for vulnerability, remove if not allowed.

Spoiler

https://www.bleepingcomputer.com/news/security/leaky-vessels-flaws-allow-hackers-to-escape-docker-runc-containers/

 

This is a good recommendation. I never considered that a podman package might actually be available for Slackware.

 

SlackBuilds.org - podman

 

It even supports uid mapping.

 

This would also avoid any conflict with switching over to rootless Docker, since we would no longer have to. Those who wish to stay running on Docker as root can continue to do so without breaking backward compatibility; those who want a little more security could switch over to podman. With some relatively light development, the web GUI frontend of Community Apps could even be configured to allow the optional use of podman (in the future; not necessary for this request).

This is a big deal. Many people mistakenly assume that LXC/OCI is inherently secure. Runtimes aren't perfectly secure AND there are many insecure container configurations out there (on Community Applications, Dockerhub, GitHub and elsewhere). This is usually to make stuff work with the least amount of pain for the greatest number of users. People providing wrapper scripts and templates aren't always putting security first or vetting the code of the projects. They aren't intentionally neglecting security and I'm not suggesting they're setting anyone up to get hacked, but the priorities tend to be functionality and ease of use no matter where you're getting free code. I'm actually less concerned with runtime vulnerability exploitation than sloppily-designed containers and templates, since the former is a bit more rare. Having rootless dockerd or rootless podman be the default container user space would prevent the worst outcomes from bad actors and malware in most cases. Commercial customers, especially, will expect a rootless option and not having that be the default will raise eyebrows in the future. Users should 100% be reviewing, at minimum, the Dockerfile for each container they install. It's easy to disguise malicious configurations as convenience or simple ignorance. Pre-built images can conceal bad stuff more easily than ones you have to build.

 

Users should also consider which components of their container stack need network access and should not connect any container to the internet, or even to their real physical LAN, unless there's a reason to. Do you need MariaDB listening on your home wifi network, or would it suffice to connect it + the containers that need to connect to it together on a local-only Docker network? (If anyone's interested in a quick rundown on how to do the latter: 

1. Turn on 'preserve custom networks' setting in Docker settings area of Unraid settings
2. Do 'docker network create --local databasenetwork' from Unraid shell
3. In the post args of a template add '&& docker network connect databasenetwork nameOfContainerThatNeedsMariaDB'
4. Proceed to update any references between the containers that need to talk to each other so they just use each hostnames' (mdns should be working out of the box with docker or podman, and as long as they share a network they should find each other by name)

)

 

When you have rootful dockerd, sans any customization efforts to lock down behavior, the software inside any container you run gets free reign to open ports and bypasses your regular ufw/firewalld/iptables/nftables rules by default. (From shell, do 'docker network ls', find your default network, then 'docker network inspect default_network_probably_eth0' ... you'll get a nice JSON printout telling you what's connected etc. , then just do a 'nc PHYSICAL_SERVER_IP_HERE PORT_NUMBER_HERE' or whatever port scanning tool you want to use. Chances are if the container wanted it open then it's bound and listening on your host's NIC.)

 

My fingers are tired so I'm calling it here. I hope the community and Lime Technology plan on taking container security more seriously as the community grows.

 

cheers

Edited January 21, 20251 yr by mankicks

18 hours ago, mankicks said:

Commercial customers, especially, will expect a rootless option and not having that be the default will raise eyebrows in the future.

unRAID is designed for consumer (home) use not commercial use. I would not recommend it for business cases. Not saying rootless containers wouldnt be nice to have though.

I am working on other servers and lxc with podman and this uses less memory and runs better with less memory.

Please add support into one of the next versions.

I've been playing around a bit in unRAID and containers, both with podman and with docker.

One key feature I would like to achieve is running "rootless".

This is for my home use, I might be called a "power user" but for my home use I want something stable, easy and secure. The secure part is the biggest driving factor why I created this RFE but I've also seen what happens when the "single point of failure", the docker daemon, breaks or becomes unstable.

---

docker seemed to be quite straight forward,

1. Clean out everything docker and do a fresh install of it

2. Edit /boot/config/go to create files touch /etc/subuid /etc/subgid

3. Add one line at the end of /boot/config/docker.cfg DOCKER_OPTS="$DOCKER_OPTS --userns-remap=default"

The problem that arises is that no container can be created. try starting a container without explicit --userns=host failes with docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "proc" to rootfs at "/proc"

So far, I haven't been able to figure out the problem... it might be something with how unRAID handles users and permissions in its special way.

---

I thought podman was going to be trickier,

To install the package I first needed to find it or compile it myself... I've done both ways by now. ( installed the one from https://forums.unraid.net/topic/152340-support-rootless-podman-as-container-runtime/#findComment-1365777 )

Installation was very straight forward, I followed https://serverlabs.com.au/blogs/guides/installing-slackware-packages-on-unraid... some dependency hell later ( i forgot to install all dependencies ) and podman was working.

Running podman without any configuration at all worked ( could be because step 2 from the docker installation was still present in /boot/config/go ), the container got downloaded and hello-world was displayed.

Then came the configuration, everything done from /boot/config/go. Create user, create /etc/{subuid,subgid}, copy configurationsfiles from /boot/config/* to their proper places.

I also created an alias for docker that points to podman... but that got a little bit tricky since unRAID seemed unsure if docker was started or not... and integrating with the webGUI is not something I got working yet.

More work needs to be done before I can say "I got podman fully working on unRAID" but it seems doable.