Open Stack

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.

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
>