Mounting host's root file system inside container security issue
huornlmj opened this issue · comments
This YAML is configuring an SRIOV container to mount the hosts's entire root file system inside the container. This is against basic containerisation best practices and can lead to escape and privilege escalation. Such misconfigurations have been exploited in a number of well known security incidents (Doki, Hildegard, Peirates, Siloscape and TeamTNT).
The solution would be to not mount the entire host root file system in the container and only mount the sub directories specifically required, basically the principle of least privilege.
Consider using the strace Linux utility to help identify the specific files and directories are are needed by your processes, and then mount only the most granular required. Also, avoid shifting the mount point down one level to one of the root's directories. I.e., do not blanket mount /dev, /proc, run, etc. or any 1st level directory.
I would consider a CVE for this.
Hi @huornlmj thanks for the update be aware that we mount this as we need the all file system in the right order so we can run chroot from inside the container
Can you explain what is being chrooted? Is it the entire host fs?
yes so we can run systemd and other host configuration
take a look on in the code for chroot function and see what we do after that command I think it will be the best to understand if we can do that in a different way :)
Why chroot inside a container though and not just mount what is needed? I would ask the question as to why the host's docker socket is mounted inside the container? As well as the hosts' /etc/shadow file, the host's setuid executable binaries (unmount, mount etc.) a full bash shell environment, the hosts' /tmp/ world-writable directory etc.. I'm naming just a small few items that are used by attackers to escape from a container and compromise the host. The principle of granting nothing and only adding what is needed is not being followed here.
Hello,
Allow me to take the opportunity at addressing the concerns
raised here, specifically regarding the use of hostPath. First off,
thanks for raising this issue. However, it's crucial to make a clear
distinction here: we view this issue as a design limitation which in
hindsight we more clearly recognize as being a flaw.
A design flaw refers to architectural decisions that might come with
disadvantages or potential for improvement. In contrast, a vulnerability
implies the existence of an exploitable issue. The use of hostPath in
our design was a conscious decision, and while it has its limitations,
it does not provide a direct path for exploitation. Hence, it may not be
accurately represented by CVSS scores, which are typically used to
quantify vulnerabilities, not design choices.
It's worth mentioning that design flaws like this one could lead to
potential exploits being less bounded. We understand the associated
risks and agree that improvements could be made. However, given the
immediate needs at hand, we are prioritizing more urgent matters and
plan to address this sort of clean-up in a future release during a
longer timeframe.
To the Intel team and other community members, we warmly welcome your expertise
and collaboration in addressing this issue. Your contributions and
pull requests could significantly enhance the security of our platform.
We greatly appreciate your input and look forward to constructive
discussions in this space.
BR,
Yuval