Support status of OpenBSD frontend drivers

Support status of OpenBSD frontend drivers

[Demi Marie Obenour]

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

As per private discussion with Theo de Raadt, OpenBSD does not consider
bugs in its xnf(4) that allow a backend to cause mischief to be security
issues.  I believe the same applies to its xbf(4).  Should the support
document be updated?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

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

Re: Support status of OpenBSD frontend drivers

[Roger Pau Monné]

On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> As per private discussion with Theo de Raadt, OpenBSD does not consider
> bugs in its xnf(4) that allow a backend to cause mischief to be security
> issues.  I believe the same applies to its xbf(4).  Should the support
> document be updated?

I think that's already reflected in the support document:

'Status, OpenBSD: Supported, Security support external'

Since the security support is external it's my understanding OpenBSD
security team gets to decide what's a security issue and what is not.

That however creates differences in the level of support offered by
the different OSes, but I think that's unavoidable. It's also hard to
track the status here because those are external components in
separate code bases.

Could be added as a mention together with the Windows note about
frontends trusting backends, but then I would fear this is likely to
get out of sync if OpenBSD ever changes their frontends to support
untrusted backends (even if not considered as a security issue).

Thanks, Roger.

Re: Support status of OpenBSD frontend drivers

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 1920 bytes --]

On 3/24/22 10:11, Roger Pau Monné wrote:
> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
>> As per private discussion with Theo de Raadt, OpenBSD does not consider
>> bugs in its xnf(4) that allow a backend to cause mischief to be security
>> issues.  I believe the same applies to its xbf(4).  Should the support
>> document be updated?
> 
> I think that's already reflected in the support document:
> 
> 'Status, OpenBSD: Supported, Security support external'
> 
> Since the security support is external it's my understanding OpenBSD
> security team gets to decide what's a security issue and what is not.
> 
> That however creates differences in the level of support offered by
> the different OSes, but I think that's unavoidable. It's also hard to
> track the status here because those are external components in
> separate code bases.
> 
> Could be added as a mention together with the Windows note about
> frontends trusting backends, but then I would fear this is likely to
> get out of sync if OpenBSD ever changes their frontends to support
> untrusted backends (even if not considered as a security issue).

As a Qubes OS developer, I still think this is useful information and
should be documented.  For instance, if I choose to add proper OpenBSD
guest support to Qubes OS (as opposed to the current “you can run
anything in an HVM” situation), I might decide to have OpenBSD
guests use devices emulated by a Linux-based stubdomain, since the
stubdomain’s netfront and blkfront drivers *are* security-supported
against malicious backends.  I might also choose to have a warning in
the GUI when switching the NetVM of an OpenBSD guest to something other
than the empty string (meaning no network access) or the (normally
fairly trusted) sys-firewall or sys-whonix qubes.

-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4963 bytes --]

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

Re: Support status of OpenBSD frontend drivers

[Marek Marczykowski-Górecki]

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

On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
> On 3/24/22 10:11, Roger Pau Monné wrote:
> > On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> >> As per private discussion with Theo de Raadt, OpenBSD does not consider
> >> bugs in its xnf(4) that allow a backend to cause mischief to be security
> >> issues.  I believe the same applies to its xbf(4).  Should the support
> >> document be updated?
> > 
> > I think that's already reflected in the support document:
> > 
> > 'Status, OpenBSD: Supported, Security support external'
> > 
> > Since the security support is external it's my understanding OpenBSD
> > security team gets to decide what's a security issue and what is not.
> > 
> > That however creates differences in the level of support offered by
> > the different OSes, but I think that's unavoidable. It's also hard to
> > track the status here because those are external components in
> > separate code bases.
> > 
> > Could be added as a mention together with the Windows note about
> > frontends trusting backends, but then I would fear this is likely to
> > get out of sync if OpenBSD ever changes their frontends to support
> > untrusted backends (even if not considered as a security issue).
> 
> As a Qubes OS developer, I still think this is useful information and
> should be documented.  For instance, if I choose to add proper OpenBSD
> guest support to Qubes OS (as opposed to the current “you can run
> anything in an HVM” situation), I might decide to have OpenBSD
> guests use devices emulated by a Linux-based stubdomain, since the
> stubdomain’s netfront and blkfront drivers *are* security-supported
> against malicious backends.  I might also choose to have a warning in
> the GUI when switching the NetVM of an OpenBSD guest to something other
> than the empty string (meaning no network access) or the (normally
> fairly trusted) sys-firewall or sys-whonix qubes.

I'm with Roger on this - when security support is external, such
information in xen.git could easily become stale. If anything, there
could be a link to OpenBSD security status info, maintained by whoever
such support provides.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

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

Re: Support status of OpenBSD frontend drivers

[Demi Marie Obenour]

[-- Attachment #1.1.1: Type: text/plain, Size: 2489 bytes --]

On 3/24/22 18:21, Marek Marczykowski-Górecki wrote:
> On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
>> On 3/24/22 10:11, Roger Pau Monné wrote:
>>> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
>>>> As per private discussion with Theo de Raadt, OpenBSD does not consider
>>>> bugs in its xnf(4) that allow a backend to cause mischief to be security
>>>> issues.  I believe the same applies to its xbf(4).  Should the support
>>>> document be updated?
>>>
>>> I think that's already reflected in the support document:
>>>
>>> 'Status, OpenBSD: Supported, Security support external'
>>>
>>> Since the security support is external it's my understanding OpenBSD
>>> security team gets to decide what's a security issue and what is not.
>>>
>>> That however creates differences in the level of support offered by
>>> the different OSes, but I think that's unavoidable. It's also hard to
>>> track the status here because those are external components in
>>> separate code bases.
>>>
>>> Could be added as a mention together with the Windows note about
>>> frontends trusting backends, but then I would fear this is likely to
>>> get out of sync if OpenBSD ever changes their frontends to support
>>> untrusted backends (even if not considered as a security issue).
>>
>> As a Qubes OS developer, I still think this is useful information and
>> should be documented.  For instance, if I choose to add proper OpenBSD
>> guest support to Qubes OS (as opposed to the current “you can run
>> anything in an HVM” situation), I might decide to have OpenBSD
>> guests use devices emulated by a Linux-based stubdomain, since the
>> stubdomain’s netfront and blkfront drivers *are* security-supported
>> against malicious backends.  I might also choose to have a warning in
>> the GUI when switching the NetVM of an OpenBSD guest to something other
>> than the empty string (meaning no network access) or the (normally
>> fairly trusted) sys-firewall or sys-whonix qubes.
> 
> I'm with Roger on this - when security support is external, such
> information in xen.git could easily become stale. If anything, there
> could be a link to OpenBSD security status info, maintained by whoever
> such support provides.

This ought to be on https://man.openbsd.org/xnf.4 and
https://man.openbsd.org/xbf.4, but it is not.  Should I send a patch?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 4963 bytes --]

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

Re: Support status of OpenBSD frontend drivers

[Roger Pau Monné]

On Thu, Mar 24, 2022 at 09:10:57PM -0400, Demi Marie Obenour wrote:
> On 3/24/22 18:21, Marek Marczykowski-Górecki wrote:
> > On Thu, Mar 24, 2022 at 11:49:14AM -0400, Demi Marie Obenour wrote:
> >> On 3/24/22 10:11, Roger Pau Monné wrote:
> >>> On Thu, Mar 24, 2022 at 09:56:29AM -0400, Demi Marie Obenour wrote:
> >>>> As per private discussion with Theo de Raadt, OpenBSD does not consider
> >>>> bugs in its xnf(4) that allow a backend to cause mischief to be security
> >>>> issues.  I believe the same applies to its xbf(4).  Should the support
> >>>> document be updated?
> >>>
> >>> I think that's already reflected in the support document:
> >>>
> >>> 'Status, OpenBSD: Supported, Security support external'
> >>>
> >>> Since the security support is external it's my understanding OpenBSD
> >>> security team gets to decide what's a security issue and what is not.
> >>>
> >>> That however creates differences in the level of support offered by
> >>> the different OSes, but I think that's unavoidable. It's also hard to
> >>> track the status here because those are external components in
> >>> separate code bases.
> >>>
> >>> Could be added as a mention together with the Windows note about
> >>> frontends trusting backends, but then I would fear this is likely to
> >>> get out of sync if OpenBSD ever changes their frontends to support
> >>> untrusted backends (even if not considered as a security issue).
> >>
> >> As a Qubes OS developer, I still think this is useful information and
> >> should be documented.  For instance, if I choose to add proper OpenBSD
> >> guest support to Qubes OS (as opposed to the current “you can run
> >> anything in an HVM” situation), I might decide to have OpenBSD
> >> guests use devices emulated by a Linux-based stubdomain, since the
> >> stubdomain’s netfront and blkfront drivers *are* security-supported
> >> against malicious backends.  I might also choose to have a warning in
> >> the GUI when switching the NetVM of an OpenBSD guest to something other
> >> than the empty string (meaning no network access) or the (normally
> >> fairly trusted) sys-firewall or sys-whonix qubes.
> > 
> > I'm with Roger on this - when security support is external, such
> > information in xen.git could easily become stale. If anything, there
> > could be a link to OpenBSD security status info, maintained by whoever
> > such support provides.
> 
> This ought to be on https://man.openbsd.org/xnf.4 and
> https://man.openbsd.org/xbf.4, but it is not.  Should I send a patch?

You should discuss with the OpenBSD people I think, I really have no
idea where those limitations should be listed. Introducing a man page
'Caveats' or 'Limitations' sections would seem suitable to me, but
it's ultimately up to them.

Thanks, Roger.