How can the root user get "permision denied" errors?
If containers run as root by default, why can't they sniff network traffic by default? What are Linux capabilities and how do they impact you?
Trivia: where does the name root come from? Answer at the bottom of this post.
Since the earliest of times, there have been two types of Linux users: regular users and the superuser â aka root.
Regular users do regular things, like browsing on reddit or using VSCode. For important administrative work - like apt-get install cowsay - they use sudo to temporarily become root.
However, traditional root is on the way out.
Whatâs wrong with the traditional root?
Itâs too powerful. When a program running as root is compromised, it can do anything. This violates the principle of least-privilege. (Thatâs a fancy way of saying, âdonât give the military gardener the keys to the nuke silo.â)
By the way, here is Midjourneyâs representation of the root user, also known as the superuser.
Why does Linux have a root user to begin with?
Traditionally, Linux security was all about file permissions. When installing new software, you wanted to just do it, donât ask about permissions dammit! So you used root.
Additional powers got attached to root over time. For example, want to capture network traffic with tcpdump? Only root can do that.
However, running tcpdump as root is an awful idea! There have been 175 vulnerabilities in tcpdump over the years. We sure as hell donât want to run tcpdump as root!
Linux capabilities split root into many parts
The problem with traditional root is that itâs all or nothing. Either you donât have permission to run tcpdump, or you do have permission to run tcpdump but also to wipe the whole hard-disk.
Capabilities break up the special things that root does into categories. You can get permission for some capabilities, without others. This greatly improves security.
Capabilities on Kubernetes
Capabilities are used on Kubernetes all the time. For example, debuggers on Kubernetes need SYS_PTRACE
capability:
apiVersion: v1
kind: Pod
metadata:
name: some-debugger
spec:
containers:
- name: debugger
image: this-example-is:unrealistically-simplistic
securityContext:
capabilities:
add: ["SYS_PTRACE"]
Donât containers run as root by default?
Ah, yes! Astute readers know that containers run as root by default (something weâll cover in the future) - so why the need to add capabilities to containers? Donât they already have all capabilities because theyâre root?
Just like capabilities can be added to regular users, they can be subtracted from root. Even when containers run as root, theyâve had a bunch of capabilities subtracted from them already. root has become something less than root.
On Kubernetes, you add/remove capabilities with Pod.spec.containers[*].securityContext.capabilities.
What other Linux security mechanisms does Kubernetes use?
Thatâs what weâll cover in the rest of this series! Subscribe as always to avoid missing out.
In case you missed them:
Series introduction - Why Linux file permissions don't provide sufficient security
Previously on WhyK8s - Why Network Policies?
Trivia answer: The root user is named after the root (/) directory, because only root can write to it. The root directory is named after the root of a tree, because file directories are like trees. So the name root comes from botany!
Programming note: Weâre moving to a bi-weekly newsletter for the near future. Natan is moving house this week, and things busier than usual at Robusta.dev. (People keep adding Robusta to their Prometheus stack, and so should you!)