Best (convenient) ways to containerise programmes?

General system Applications
1

VMs are great but they’re pretty resource heavy. Firejail is ok too but doesn’t do quite what I want (have a programme’s files reside in a separate directory and have as little as possible a relationship with the OS). I’ve heard of Docker, is it what I think it is? Basically, my idea is, it’ll give me the containerisation/isolation of files from my main system (like a VM) without the performance penalties of a VM. Are there other technologies for containerisation (I know of flatpak, but that only seems to work as a sandbox for gui apps).

Specifically, I want to install khan-dl but don’t want it to infest my main system. Similarly, I want to code (and run) a discord bot with nodejs but want it to not touch my main OS. Is there an easy way to do this?

2

If there is a Docker image, it is likely your best option. It will likely not touch your main OS other than where you choose to store it, but it is still run on it. If you absolutely do not want any connection between your bot and your main OS, then your best option would be to pick up a raspberry pi or similar device and run it on there.

edit: couldn’t find a khan-dl docker image with a quick search, but this seems to have similar (if not better) functionality. Perhaps it is sufficient for your needs.

3

Containers don’t provide isolation like VMs. If you want full isolation, use a VM. If you want a way of bundling an application and its library requirements, use a container.

2 Likes
4

So, can a programme possible ‘escape’ the container if it wants to?

Thanks. I ended up installing pip in the archlinux docker image and using khan-dl from there.

1 Like
5

Depends on the container and its security model, but certainly historically you don’t run untrusted code in containers.

6

docker is becoming deprecated (& has already been deprecated by Red Hat) so you probably want to use podman to run containers instead as it’s a drop in replacement for docker. From a security perspective podman is relatively simple to run rootless (as long as you don’t mind the security implications of enabling user namespaces)

khan-dl is a python app so really all you need is a python virtualenv to not pollute your system python. I do this with linkding (a python / nodejs app) - the development section here shows you how to setup a virtualenv. I use this solution so I don’t need to enable user namespaces - & run the app through firejail for isolation.

Another option would be to setup an Alpine Linux LXD container & bind mount a local directory to it so you have easy access to the downloads. Alpine LXD containers are very lightweight & idle using around 16mb of RAM & use around 5mb of disk space. LXD containers can be run unprivileged which is nice (root in the container is just a user on the bare metal system).

7

I thought using user namespaces was better from a security standpoint?

8

Allowing a user namespace to only be created by root is more secure (this is the default in linux-hardened)

To allow a normal $USER to create namespaces:

For the implications of allowing an unprivileged user to create namespaces see Stack Exchange.

I run unprivileged containers started by root (root in the container is still just a $USER on the bare metal host)

9

So I’ve been using firejail all this time using the user namespaces feature, because archwiki page on firejail leads you to believe it is a desirable one. The user namespaces created by firejail are created by $USER, right? So, that shouldn’t be done right? I can guess this isn’t simply a yes/no question but I honestly don’t feel like looking too much into this right now.

10

I use firejail too - I think it has the suid bit set on the executable (as I use it with kernel.unprivileged_userns_clone = 0)

  • To further improve security boot your kernel with module.sig_enforce=1 (to help prevent rootkits being installed)

If you use ‘out of tree’ modules (e.g zfs / nvidia / p_lkrg - anything using dkms) - you can build a kernel which will sign ‘out of tree’ modules too with arch-sign-modules.