Linux Capabilities with User Namespaces

Setting capability on the script will not be effective. It's the similar situation as not working setuid bit on script. Similar as in the latter case it's the implementation of how execve handles shebang and the security reasoning behind it (for details see: Allow setuid on shell scripts).

I think you have these options

1. set the capabilities on interpreter itself (actually rather a copy of it)

   • you have a problem here that anybody who is able to execute it will run with those elevated capabilities (be able to execute some arbitrary script or start it interactively)

2. write a wrapper executable which will have a hardcoded logic to execute your script, and set desired capabilities on this executable

   • make sure that nobody is able to modify nor remove / replace the script
   • still by doing chroot one might missuse such wrapper

In both cases you would have to make sure capabilities set will survive execve by setting inheritable flag. You might also use pam_cap distributed with libcap usually, to actually activate desired capabilities by configuration only for selected users.

And in general you want to make sure nobody is able to modify behavior of your interpreter by changing environment eg. PYTHON_PATH or something similar.

In a nutshell, namespaces provide a way to build a virtual Linux system inside a larger Linux system. This is different from running a virtual machine that runs as an unprivileged process: the virtual machine appears as a single process in the host, whereas processes running inside a namespace are still running on the host system.

A virtual system running inside a larger system is called a container. The idea of a container is that processes running inside the container believe that they are the only processes in the system. In particular, the root user inside the container does not have root privileges outside the container (note that this is only true in recent enough versions of the kernel).

Namespaces virtualize one feature at a time. Some examples of types of namespaces are:

• User namespaces — this allows processes to behave as if they were running as different users inside and outside the namespace. In particular, processes running as UID 0 inside the namespace have superuser privileges only with respect to processes running in the same namespace.
  Since Linux kernel 3.8, unprivileged users can create user namespaces. This allows an ordinary user to make use of features that are reserved to root (such as changing routing tables or setting capabilities).
• PID namespaces — processes inside a PID namespace cannot kill or trace processes outside that namespace.
• Mount namespaces — this allows processes to have their own view of the filesystem. This view can be a partial view, allowing some pieces of the filesystem to be hidden and pieces to be recomposed so that directory trees appear in different places. Mount namespaces generalize the traditional Unix feature chroot, which allows processes to be restricted to a particular subtree.
• Network namespaces — allow separation of networking resources (network devices) and thus enhance isolation of processes.

Namespaces rely on the kernel to provide isolation between namespaces. This is quite complicated to get right, so there may still be security bugs lying around. The risk of security bugs would be the primary reason not to enable the feature. Another reason not to enable it would be when you're making a small kernel for an embedded device. In a general-purpose kernel that you'd install on a typical server or workstation, namespaces should be enabled, like any other mature kernel feature.

There are still few applications that make use of namespaces. Here are a few:

• LXC is well-established. It relies on cgroups to provide containers.
• virt-sandbox is a more recent sandboxing project.
• Recent versions of Chromium also use namespaces for sandboxing where available.
• The uWSGI framework for clustered applications uses namespaces for improved sandboxing.

See the LWN article series by Michael Kerrisk for more information.