On 27 Apr 2021, at 13:34, Peng Tao via kata-dev <kata-dev@lists.katacontainers.io> wrote:



On 2021/4/26 23:51, Stefan Hajnoczi wrote:
On Wed, Apr 14, 2021 at 07:41:32PM +0800, Peng Tao wrote:


On 2021/4/14 16:37, Stefan Hajnoczi wrote:
On Wed, Apr 14, 2021 at 11:41:41AM +0800, Peng Tao wrote:
On 2021/4/12 22:46, Stefan Hajnoczi wrote:
On Wed, Apr 07, 2021 at 05:07:05PM -0700, Eric Ernst wrote:
On Thu, Apr 1, 2021 at 7:58 AM Stefan Hajnoczi <stefanha@redhat.com> wrote:
On Mon, Mar 29, 2021 at 04:49:31PM -0700, Eric Ernst wrote:

BTW, one aspect of the draft that isn't clear to me:

    the CSI driver will create a particular file, csiPlugin.json at the root of the volume on the host

Can a malicious user put a csiPlugin.json file onto a persistent volume
and then attach it to a Kata-enabled container to get the runtime and/or
agent to execute mount commands either on the host or in the sandbox VM?

It is possible but it violates the current kata threat model, which is
basically we'd have to trust the host. If a user is able to gain root
privilege on the host, he/she is capable of doing anything to kata.

That said, it is indeed possible to mitigate this by using an RPC based
approach between csi and kata.

If the host is already compromised then I don't expect Kata to protect
anything.

My question was about k8s persistent volumes. I wanted to check that the
csiPlugin.json file is not interpreted if present on a persistent
volume. It should only be interpreted when the CSI driver places it
there on the host. The text wasn't completely clear on whether the "root
of the volume on the host" refers to the contents of the persistent
volume itself (that's unsafe) or to the container runtime's host path
(that's safe).


Ah, good point! Kata needs to differentiate between a PV containing a
csiPlugin.json file in it, and a CSI driver "hacked" host path. They are
both host directories from Kata's point of view.

A possible method is to check if the host path is a mountpoint. Then
1. do not ever try to parse the csiPlugin.json file if it is a mountpoint,
and
2. require csi to ensure that the volume host directory is not a mountpoint
(IOW do not mount the volume to the host directory)

wdyt?
It would be nice if there was an explicit way for kata-runtime to know
whether it's looking at a host directory set up by a CSI plugin or an
actual mounted PV.
Hmm, an API based approach is a good candidate of such an explicit way.

Isn't that what your "open a port to communicate with CSI" approach did?


Cheers,
Tao
The mount point trick sounds okay but I worry that maybe in some
environments the directory might be a mount point and that would result
in a false positive.
I don't have a specific suggestion though because I haven't looked at
this in detail.
> Stefan

_______________________________________________
kata-dev mailing list
kata-dev@lists.katacontainers.io
http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev