Open Stack

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

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/20210414/985daa45/attachment-0001.sig>