Open Stack

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 at 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210426/b8c90f94/attachment.sig>