Re: Sandboxing strategy

Alyssa Ross
2025-09-17T11:27:31Z

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 9/10/25 11:11, Alyssa Ross wrote:
>> This all sounds fine, BUT there are a couple of important things to bear
>> in mind:
>>
>> • This needs to be maintainable. I don't know how much code this is
>> going to be our how complex it's going to be, but that this will be
>> totally custom does make me a bit concerned.
>
> This should not be too difficult. It's the same system calls used by
> container managers, so if there is a problem it should be possible to
> get help fairly easily. bubblewrap

bubblewrap? :)

>> • These services are part of our TCB anyway. Sandboxing only gets us
>> defense in depth. With that in mind, it's basically never going to
>> be worth adding sandboxing if it adds any amount of attack surface.
>> One example of that would be user namespaces. They've been a
>> consistent source of kernel security issues, and it might be better
>> to turn them off entirely than to use them for sandboxing stuff
>> that's trusted anyway.
>
> Sandboxing virtiofsd is going to be really annoying and will definitely
> come at a performance cost. The most efficient way to use virtiofsd
> is to give it CAP_DAC_READ_SEARCH in the initial user namespace and
> delegate _all_ access control to it. This allows virtiofs to use
> open_by_handle_at() for all filesystem access. Unfortunately,
> this also allows virtiofsd to open any file on the filesystem, ignoring
> all discretionary access control checks. I don't think Landlock would
> work either. SELinux or SMACK might work, but using them is
> significantly more complicated.
>
> If one wants to sandbox virtiofsd, one either needs to
> use --cache=never or run into an effective resource leak
> (https://gitlab.com/virtio-fs/virtiofsd/-/issues/194).
> My hope is that in the future the problem will be solved
> by DAX and an in-kernel shrinker that is aware of the host
> resources it is using. Denial of service would be prevented
> by cgroups on the host, addressing the objection mentioned
> in the issue comments.

Do we not trust virtiofsd's built-in sandboxing?