node_exporter icon indicating copy to clipboard operation
node_exporter copied to clipboard

Docker and mounting host rootfs security concern

Open huornlmj opened this issue 3 years ago • 7 comments

According to the documentation (https://github.com/prometheus/node_exporter#docker) the use of docker is "not recommended" but that if there are reasons requiring it the documentation then goes onto advise to mount the hosts root file system. Some downstream consumers are choosing the containerization option and overlooking your advice not to containerize but also interpreting the guidance to mount the host file system as Prometheus's best known method. My suggestion would be while advising not to containerize, also advise that if it is a must that more granular mounting is performed instead of a blanket host fs mount, albeit read only.

huornlmj avatar Dec 28 '21 11:12 huornlmj

We could try bind-mounting /proc and /sys instead. But I think we might also need to bind-mount all mountpoints for filesystems you want to monitor which probably isn't feasible. That being said, I'm not too concerned about a blanket host fs mount. Running the node-exporter without any containerization isn't more secure either, right? If there should be a bug leading to file disclosure or even code execution, the impact when running on the host is arguably at least as high as this happening in a container with rootfs mount read-only.

discordianfish avatar Dec 29 '21 10:12 discordianfish

Take a look at my comment here. I think we could work around mounting required for the os collector. So, it really comes down to whether we can get the filesystem collector to no longer use the whole filesystem. Is there a way to collect disk use info for filesystem through /sys and /proc only? If so, we can limit the "/" mount to just the two files needed by the os collector. You still may need to mount "/<something" for collectors that use arbitrary directories like textfile. But that is doable too.

So, can filesystem get what it needs without "/"?

Boojapho avatar Feb 10 '22 02:02 Boojapho

We call Statsfs() on the mountpoints, so if you want to monitor them you'll need to bind-mount them: https://github.com/prometheus/node_exporter/blob/f7086d437bc0b652ad56fe1a775b1994d7076796/collector/filesystem_linux.go#L80

If you find a better way, open to discuss.

But to clarify: The node-exporter runs as unprivileged user, so even with the the / host fs mount it wouldn't have access to anything that isn't world-readable.

discordianfish avatar Feb 10 '22 23:02 discordianfish

Unfortunately, I couldn't find a better way

Boojapho avatar Feb 17 '22 15:02 Boojapho

I believe having the hosts' docker socket file mounted inside the container, privilege level aside, is a security risk. Over-the-top volume mounting has been the root cause of a number of container escape vulnerabilities before. It also goes against the principle of least privilege. Has anyone tried using strace on the process to see exactly what files it needs access to in order to function properly, and then find the highest common directory mounts that match and just mount those instead of the host / ?

huornlmj avatar Aug 11 '22 14:08 huornlmj

It's /proc, /sys and every mountpoint

discordianfish avatar Aug 22 '22 13:08 discordianfish

Hi !

Wouldn't there be a way to mount the container with a specific fs driver configured to "reflect" the host filesystem without having to mount the whole host rootfs into the container ?

Don't know a lot about fs drivers, but I notice that through my container shell, calling statfs on container rootfs returns the exact same output than calling statfs on my host, as I suppose statfs call on overlay is 'piped' to host rootfs ?

Is this just based on my current configuration or can be "generalized" ? Otherwise why couldn't it be ?

example with df:

<my-user>@<my-server>~$ df | grep -P "/$" && docker exec -it node bash -c 'df | grep -P "/$"'
/dev/sda1       82394940 22146812  56861972  29% /
overlay         82394940 22146816  56861968  29% /

Thanks !

rcrestey avatar Feb 04 '24 16:02 rcrestey