Nous nous sommes intéressés récemment aux Linux Capabilities , dans le cadre de durcissement de containers Docker ou de cluster Kubernetes.
Il existe de nombreuses références à ce sujet sur Internet et dépasse l’objet de cet article.
Les Capabilities , intégrées aux Kernel Linux, permettent de décrire finement les droits nécessaires à un exécutable et sont référencées ici. Celles qui nous intéressent le plus souvent dans le cas du confinement de containers Docker sont :
/* Allow interface configuration */ /* Allow administration of IP firewall, masquerading and accounting */ /* Allow setting debug option on sockets */ /* Allow modification of routing tables */ /* Allow setting arbitrary process / process group ownership on sockets */ /* Allow binding to any address for transparent proxying (also via NET_RAW) */ /* Allow setting TOS (type of service) */ /* Allow setting promiscuous mode */ /* Allow clearing driver statistics */ /* Allow multicasting */ /* Allow read/write of device-specific registers */ /* Allow activation of ATM control sockets */ #define CAP_NET_ADMIN 12 /* Allow use of RAW sockets */ /* Allow use of PACKET sockets */ /* Allow binding to any address for transparent proxying (also via NET_ADMIN) */ #define CAP_NET_RAW 13
Un exemple de classique utilise le binaire « ping » :
root@srn:~# ls -lh /bin/ping -rwsr-xr-x 1 root root 44K May 7 2014 /bin/ping
On constate que le bit S (setuid) est activé car ping nécessite le droit de créer une socket ICMP. Si « root » retire ce droit, le ping ne fonctionne plus pour l’utilisateur « toto »:
# chmod -s /bin/ping # su toto $ ping randco.fr ping: icmp open socket: Operation not permitted
Si on ajoute la Capability NET_RAW, ping fonctionne à nouveau et ce nouveau droit est à la fois suffisant et bien plus restreint qu’un bit SETUID :
# setcap cap_net_raw+p /bin/ping # su toto $ ping randco.fr PING randco.fr (164.132.216.245) 56(84) bytes of data. 64 bytes from 164.132.216.245: icmp_seq=1 ttl=57 time=5.72 ms 64 bytes from 164.132.216.245: icmp_seq=2 ttl=57 time=5.30 ms
Dans Kubernetes, les Pod Security Policies (PSP) permettent de détailler au niveau du Cluster les Capabilities à ajouter ou à retirer aux Pods. Ci-dessous un exemple de Policy très contrainte :
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
# This is redundant with non-root + disallow privilege escalation,
# but we can provide it for defense in depth.
requiredDropCapabilities:
- ALL
[..]
Pour apprendre par le test, nous ne pouvons que vous conseiller d’explorer https://contained.af/.
Si vous avez des questions plus globales sur la sécurisation de cluster Kubernetes, contactez-nous.