Why is /run/vm/by-id/${VM} writable by the VMM?

Why is /run/vm/by-id/${VM} writable by the VMM?

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 340 bytes --]

This seems to be a fairly significant hole in the VMM's sandbox.
Various code operates in that directory and isn't secure against
symlink attacks.

Does the VMM really need write access to that directory?  Could it
be given access to a subdirectory that is mounted "nosymfollow"?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Alyssa Ross]

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

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

> This seems to be a fairly significant hole in the VMM's sandbox.
> Various code operates in that directory and isn't secure against
> symlink attacks.
>
> Does the VMM really need write access to that directory?  Could it
> be given access to a subdirectory that is mounted "nosymfollow"?

I think it's just so it can create e.g. the serial file.  That could
indeed be moved to a subdirectory.  The ideal solution is of course for
Cloud Hypervisor to be able to accept every file it would otherwise
create as an open file descriptor, which I expect will happen
eventually.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 856 bytes --]

On 7/13/26 05:04, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
> 
>> This seems to be a fairly significant hole in the VMM's sandbox.
>> Various code operates in that directory and isn't secure against
>> symlink attacks.
>>
>> Does the VMM really need write access to that directory?  Could it
>> be given access to a subdirectory that is mounted "nosymfollow"?
> 
> I think it's just so it can create e.g. the serial file.  That could
> indeed be moved to a subdirectory.  The ideal solution is of course for
> Cloud Hypervisor to be able to accept every file it would otherwise
> create as an open file descriptor, which I expect will happen
> eventually.

Should it be moved to a subdirectory for now?  That would make the
sandbox meaningful in practice.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Alyssa Ross]

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

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

> On 7/13/26 05:04, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> This seems to be a fairly significant hole in the VMM's sandbox.
>>> Various code operates in that directory and isn't secure against
>>> symlink attacks.
>>>
>>> Does the VMM really need write access to that directory?  Could it
>>> be given access to a subdirectory that is mounted "nosymfollow"?
>> 
>> I think it's just so it can create e.g. the serial file.  That could
>> indeed be moved to a subdirectory.  The ideal solution is of course for
>> Cloud Hypervisor to be able to accept every file it would otherwise
>> create as an open file descriptor, which I expect will happen
>> eventually.
>
> Should it be moved to a subdirectory for now?  That would make the
> sandbox meaningful in practice.

I suppose it could be.  Might make more sense to dedicate efforts
towards fixing Cloud Hypervisor to accept file descriptors for the ~2
paths it currently needs to create, though.  (That's obviously more
work, but also more useful.)  If we were to work around this in
Spectrum, we could keep symlinks outside the directory pointing into it,
to keep paths nice and avoid churn once we can put them back in the
parent directory.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 1489 bytes --]

On 7/15/26 14:54, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
> 
>> On 7/13/26 05:04, Alyssa Ross wrote:
>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>
>>>> This seems to be a fairly significant hole in the VMM's sandbox.
>>>> Various code operates in that directory and isn't secure against
>>>> symlink attacks.
>>>>
>>>> Does the VMM really need write access to that directory?  Could it
>>>> be given access to a subdirectory that is mounted "nosymfollow"?
>>>
>>> I think it's just so it can create e.g. the serial file.  That could
>>> indeed be moved to a subdirectory.  The ideal solution is of course for
>>> Cloud Hypervisor to be able to accept every file it would otherwise
>>> create as an open file descriptor, which I expect will happen
>>> eventually.
>>
>> Should it be moved to a subdirectory for now?  That would make the
>> sandbox meaningful in practice.
> 
> I suppose it could be.  Might make more sense to dedicate efforts
> towards fixing Cloud Hypervisor to accept file descriptors for the ~2
> paths it currently needs to create, though.  (That's obviously more
> work, but also more useful.)  If we were to work around this in
> Spectrum, we could keep symlinks outside the directory pointing into it,
> to keep paths nice and avoid churn once we can put them back in the
> parent directory.

Do you happen to know which paths these are?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Alyssa Ross]

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

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

> On 7/15/26 14:54, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> On 7/13/26 05:04, Alyssa Ross wrote:
>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>
>>>>> This seems to be a fairly significant hole in the VMM's sandbox.
>>>>> Various code operates in that directory and isn't secure against
>>>>> symlink attacks.
>>>>>
>>>>> Does the VMM really need write access to that directory?  Could it
>>>>> be given access to a subdirectory that is mounted "nosymfollow"?
>>>>
>>>> I think it's just so it can create e.g. the serial file.  That could
>>>> indeed be moved to a subdirectory.  The ideal solution is of course for
>>>> Cloud Hypervisor to be able to accept every file it would otherwise
>>>> create as an open file descriptor, which I expect will happen
>>>> eventually.
>>>
>>> Should it be moved to a subdirectory for now?  That would make the
>>> sandbox meaningful in practice.
>> 
>> I suppose it could be.  Might make more sense to dedicate efforts
>> towards fixing Cloud Hypervisor to accept file descriptors for the ~2
>> paths it currently needs to create, though.  (That's obviously more
>> work, but also more useful.)  If we were to work around this in
>> Spectrum, we could keep symlinks outside the directory pointing into it,
>> to keep paths nice and avoid churn once we can put them back in the
>> parent directory.
>
> Do you happen to know which paths these are?

I think it might just be "serial"?  Not sure.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Demi Marie Obenour]

[-- Attachment #1.1: Type: text/plain, Size: 1797 bytes --]

On 7/21/26 12:05, Alyssa Ross wrote:
> Demi Marie Obenour <demiobenour@gmail.com> writes:
> 
>> On 7/15/26 14:54, Alyssa Ross wrote:
>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>
>>>> On 7/13/26 05:04, Alyssa Ross wrote:
>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>>
>>>>>> This seems to be a fairly significant hole in the VMM's sandbox.
>>>>>> Various code operates in that directory and isn't secure against
>>>>>> symlink attacks.
>>>>>>
>>>>>> Does the VMM really need write access to that directory?  Could it
>>>>>> be given access to a subdirectory that is mounted "nosymfollow"?
>>>>>
>>>>> I think it's just so it can create e.g. the serial file.  That could
>>>>> indeed be moved to a subdirectory.  The ideal solution is of course for
>>>>> Cloud Hypervisor to be able to accept every file it would otherwise
>>>>> create as an open file descriptor, which I expect will happen
>>>>> eventually.
>>>>
>>>> Should it be moved to a subdirectory for now?  That would make the
>>>> sandbox meaningful in practice.
>>>
>>> I suppose it could be.  Might make more sense to dedicate efforts
>>> towards fixing Cloud Hypervisor to accept file descriptors for the ~2
>>> paths it currently needs to create, though.  (That's obviously more
>>> work, but also more useful.)  If we were to work around this in
>>> Spectrum, we could keep symlinks outside the directory pointing into it,
>>> to keep paths nice and avoid churn once we can put them back in the
>>> parent directory.
>>
>> Do you happen to know which paths these are?
> 
> I think it might just be "serial"?  Not sure.

How difficult would it be to modify Cloud Hypervisor so this is passed
as a file descriptor?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Why is /run/vm/by-id/${VM} writable by the VMM?

[Alyssa Ross]

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

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

> On 7/21/26 12:05, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>> 
>>> On 7/15/26 14:54, Alyssa Ross wrote:
>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>
>>>>> On 7/13/26 05:04, Alyssa Ross wrote:
>>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>>>
>>>>>>> This seems to be a fairly significant hole in the VMM's sandbox.
>>>>>>> Various code operates in that directory and isn't secure against
>>>>>>> symlink attacks.
>>>>>>>
>>>>>>> Does the VMM really need write access to that directory?  Could it
>>>>>>> be given access to a subdirectory that is mounted "nosymfollow"?
>>>>>>
>>>>>> I think it's just so it can create e.g. the serial file.  That could
>>>>>> indeed be moved to a subdirectory.  The ideal solution is of course for
>>>>>> Cloud Hypervisor to be able to accept every file it would otherwise
>>>>>> create as an open file descriptor, which I expect will happen
>>>>>> eventually.
>>>>>
>>>>> Should it be moved to a subdirectory for now?  That would make the
>>>>> sandbox meaningful in practice.
>>>>
>>>> I suppose it could be.  Might make more sense to dedicate efforts
>>>> towards fixing Cloud Hypervisor to accept file descriptors for the ~2
>>>> paths it currently needs to create, though.  (That's obviously more
>>>> work, but also more useful.)  If we were to work around this in
>>>> Spectrum, we could keep symlinks outside the directory pointing into it,
>>>> to keep paths nice and avoid churn once we can put them back in the
>>>> parent directory.
>>>
>>> Do you happen to know which paths these are?
>> 
>> I think it might just be "serial"?  Not sure.
>
> How difficult would it be to modify Cloud Hypervisor so this is passed
> as a file descriptor?

I don't expect it would be very hard.  It's recently been done for
e.g. VFIO FDs, but I also don't think I have any special knowledge here
that you don't?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]