Open Stack

> On 27 Apr 2021, at 13:34, Peng Tao via kata-dev <kata-dev at 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 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.
> 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 at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.katacontainers.io/pipermail/kata-dev/attachments/20210428/375b7665/attachment-0001.html>