Singularity 3.0 introduces many new security related options to the container runtime. This document will describe the new methods users have for specifying the security scope and context when running Singularity containers.
It is extremely important to recognize that granting users Linux
capabilities with the
capability command group is usually identical
to granting those users root level access on the host system. Most if not
all capabilities will allow users to “break out” of the container and
become root on the host. This feature is targeted toward special use cases
(like cloud-native architectures) where an admin/developer might want to
limit the attack surface within a container that normally runs as root.
This is not a good option in multi-tenant HPC environments where an admin
wants to grant a user special privileges within a container. For that and
similar use cases, the fakeroot feature is a better
Singularity provides full support for granting and revoking Linux capabilities
on a user or group basis. For example, let us suppose that an admin has
decided to grant a user (named
pinger) capabilities to open raw sockets so
that they can use
ping in a container where the binary is controlled via
capabilities. For information about how to manage capabilities as an admin
please refer to the
capability admin docs.
To take advantage of this granted capability as a user,
pinger must also
request the capability when executing a container with the
$ singularity exec --add-caps CAP_NET_RAW library://sylabs/tests/ubuntu_ping:v1.0 ping -c 1 220.127.116.11 PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199: icmp_seq=1 ttl=52 time=73.1 ms --- 188.8.131.52 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 73.178/73.178/73.178/0.000 ms
If the admin decides that it is no longer necessary to allow the user
pinger to open raw sockets within Singularity containers, they can revoke
the appropriate Linux capability and
pinger will not be able to add that
capability to their containers anymore:
$ singularity exec --add-caps CAP_NET_RAW library://sylabs/tests/ubuntu_ping:v1.0 ping -c 1 184.108.40.206 WARNING: not authorized to add capability: CAP_NET_RAW ping: socket: Operation not permitted
Another scenario which is atypical of shared resource environments, but useful in cloud-native architectures is dropping capabilities when spawning containers as the root user to help minimize attack surfaces. With a default installation of Singularity, containers created by the root user will maintain all capabilities. This behavior is configurable if desired. Check out the capability configuration and root default capabilities sections of the admin docs for more information.
Assuming the root user will execute containers with the
capability by default, executing the same container
pinger executed above
works without the need to grant capabilities:
# singularity exec library://sylabs/tests/ubuntu_ping:v1.0 ping -c 1 220.127.116.11 PING 18.104.22.168 (22.214.171.124) 56(84) bytes of data. 64 bytes from 126.96.36.199: icmp_seq=1 ttl=52 time=59.6 ms --- 188.8.131.52 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 59.673/59.673/59.673/0.000 ms
Now we can manually drop the
CAP_NET_RAW capability like so:
# singularity exec --drop-caps CAP_NET_RAW library://sylabs/tests/ubuntu_ping:v1.0 ping -c 1 184.108.40.206 ping: socket: Operation not permitted
And now the container will not have the ability to create new sockets, causing
ping command to fail.
--drop-caps options will accept the
Of course appropriate caution should be exercised when using this keyword.
Building encrypted containers
Beginning in Singularity 3.4.0 it is possible to build and run encrypted containers. The containers are decrypted at runtime entirely in kernel space, meaning that no intermediate decrypted data is ever present on disk. See encrypted containers for more details.