Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, May 30, 2024 at 05:20:04PM -, qubist wrote: > On Wed, 29 May 2024 14:51:36 -0400 Demi Marie Obenour wrote: > > > Qubes OS only knows how to manage Xen interfaces. It does not (and, > > realistically, cannot) know how to manage every kind of network > > interface imaginable. > > In such case, it cannot do this too: > > > [...] the network interface must not be brought up at all, to prevent > > a spoofing vulnerability. > > as it is not up to Qubes to do it, right? Correct. > Or how will it bring an interface up/down if it cannot control it? > > As for sys-net and its self-managed (uplink) interfaces: this means any > such interface can have its group changed, thus circumvent the > group-based antispoofing chain you suggest. Actually, sys-net can > simply 'sudo nft flush ruleset' which is extremely easy with default > passwordless root, so does it really matter what firewall rules we > attempt to enforce? > I don't know if I am overthinking it, but for all that to work > properly, an external control mechanism is necessary (another qube). I > don't know if there is ARP antispoofing mechanism either. > > I hope you can clarify. Qubes OS's current firewall treats any interface in group 2 as if it were a Xen vif* interface, and prevents downstream spoofing by any interface _not_ in group 2. Common network management packages assign all devices to group 0 by default, so this works fine. Being able to assign non-managed devices to group 2 is intentional, not a bug. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmZYygkACgkQsoi1X/+c IsGSSw/+P7nD30ot5cHsZPgKz5DR6+zX+YYTMjZm1k5hC3sCOKM7AmyyaIxCk4OV /79JA1OOu/J0IC7vzlrc3o92Ix0/3segH4Ag6XbtCnLAxgJX8K6t5wgg3ySCxmMt mIRlhUXCTL3t36H7l2wjpLGcq4iMqOUw0mcdudmgEW0YwDkR7GoI1sOZfr4f/kle QQlnLkvjHojL/Fhit41XyQCwEarHlAVXAZ3ACWMlzBwfwxaaXQ4KM4QZTUnEkRDM MX6zriV8cOnv5ZnQFgBZ04u7UfQJN/XvpCnp9CKqAJDg9j1QDQiBnUL4rgoqJgDr vzBysAAgdReB4WoTnHV5DWfnp4GiQgI+Vx4NXOOqMS5LIyIG2cMMkoZVBRP00CWy 0q0ToCHQCpsReQo0xzUvNPnYJPBoSrTmi5JJai4r3Gd9g+W7jKtJ/yrPAJ+VLRMY cKSRQ8q2rUJhCiwbvqsZHa71o+LOYPQapJ0fvpd45HNJI6WgIVTMpIfspkaVVanM qDLDyxLIkmWABtWjrMjFaaSb7KlTii7RaM+9wPH6VFlUkYrPADzb7O0+a92xVODj ezrsgzafQyphacv+rdzIMQJt+msLKYhismuv/75RSndFoGBXT80T1qi3fyYqlSZT Gk+vMrN0hgdM7OYHzLsaTDo4fduEA48L9LNbT9fJHKhjsLoamBo= =kHQG -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZljKCTrG1RvlqYCs%40itl-email.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, May 29, 2024 at 04:07:45PM -, qubist wrote: > On Tue, 28 May 2024 16:49:51 -0400 Demi Marie Obenour wrote: > > > additional interfaces that are not managed by Qubes OS > > Why not? > Can't we have them managed, similar to the vifs? Qubes OS only knows how to manage Xen interfaces. It does not (and, realistically, cannot) know how to manage every kind of network interface imaginable. > > to block the interface being brought online if something went wrong > > Could you elaborate? If there is an error setting up the anti-spoofing firewall rules, the network interface must not be brought up at all, to prevent a spoofing vulnerability. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmZXeTcACgkQsoi1X/+c IsHIxw//W9Ri+GHmabTqGQWiVcvAT76gJFWZIEpUVkHJ4e3R9yXpQpcI+8EfLnQ6 bZe6nq2QGsKxMA2hvkzo70Oh/a1oY/cyY9iOPCBD463Vi3y9f5SxoWce2Z0AdEfK UFou1LuELyQoQqfXEob5Zl8BeWN9cWFieC6HJwHe7fFetacsQKAfHei7+n9grEEc Dc+DKYnX2pdx+Erc0CJMr75nr2wSTAx/0oAVJXdGFK0HMMgOgpoN0i1X9YXk6wEF F7BIpHZnFaHS8p9vTWxTKYIcPlgz14cxIs/CDZ2RNpRy/F5oaZL29XnzxgkIyJ2V U+oKO0IyjMvWx+aU7PeBa0kNi2YFKt3AFjQy050D8dbumWMjNIhPvnofeSFqY3rc +YZQAOfaCo7Ck9zUwRNTsY3NlO+SXOKB1w0jba88qzqMFQ8pfcm8sGjkfIV6Vpu6 UGyNuSEG/MHMGTEN4I97xzLggBYo9OzZ/Zu9lyymnuJ5nfvwIJk3RiST3h6XFWME h/gCpxc9pQlM5lV7kWTqN3xcVfqjlim1joxC+6B382GGFyCRFqN3MepvUOTL7f1b /E7vyw6UJqG+8sUuq6w5vJkTjTEMXEFCUxxPjOoJwhwWEFSw8FEcRpYchYBWUodd PWbEIFvJc+p1SP0pzMyPSwu4hJe6uTtxuRqCMl7Nw4gcvoHu+hY= =pddU -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zld5OPIE99TolJeD%40itl-email.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Tue, May 28, 2024 at 07:07:56PM -, qubist wrote:
> On Fri, 24 May 2024 15:59:04 +0200 Marek Marczykowski-Górecki wrote:
>
> > Can you clarify your description of the downstream set here? I think you
> > do need to have some drop rule somewhere.
>
> Here is what the updated script gives for 2 client qubes: one IPv4-only
> and one IPv6:
>
> table netdev antispoof {
> set downstream_ipv4 {
> type ipv4_addr
> elements = { 10.137.0.11, 10.137.0.88 }
> }
>
> set downstream_ipv6 {
> type ipv6_addr
> elements = { fd09:24ef:4179::a89:b }
> }
>
> chain downstream {
> type filter hook ingress device "eth0" priority -500; policy
> accept;
> ip saddr @downstream_ipv4 counter packets 0 bytes 0 drop
> ip6 saddr @downstream_ipv6 counter packets 0 bytes 0 drop
> }
>
> chain antispoof-vif18-0 {
> type filter hook ingress device "vif18.0" priority -500;
> policy drop;
> iifgroup 2 ip saddr 10.137.0.11 accept
> iifgroup 2 ip6 saddr fd09:24ef:4179::a89:b accept
> counter packets 14 bytes 968
> }
>
> chain antispoof-vif30-0 {
> type filter hook ingress device "vif30.0" priority -500;
> policy drop;
> iifgroup 2 ip saddr 10.137.0.88 accept
> counter packets 11 bytes 704
> }
> }
>
> Maybe we should get rid of the "iifgroup 2", since it is clear which
> exact device each chain handles?
Yes, the "iffgroup 2" is redundant in this case. I initially added
interface groups to support VPN setups, as matching on them is faster
and simpler than matching on source interface by name.
How do you plan to handle sys-net and VPN qubes? These have additional
interfaces that are not managed by Qubes OS, and they might also try to
inject spoofed packets. The simplest solution is something like
chain antispoof_downstream {
type filter hook prerouting priority raw; policy accept;
iifgroup != 2 ip saddr @downstream counter drop
}
but this might defeat the performance improvements as it brings back a
prerouting hook. A netdev hook on every interface would work, but it
would need to block the interface being brought online if something went
wrong, and I’m not aware of any way to do that.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmZWQ28ACgkQsoi1X/+c
IsHUMA//UjP30UKPx5xIl+ZZZlBA+wEJ+pxXvsm3pdFDhqc3YtIvLQYJKvLzJrHJ
0POMm1s1ySb8coSSduE1+CK3Hk1jSEerP87tbbBJ1jUmkBugYSMNRHEBMMGmQWlg
wzfeSp/+kr0UzQ8LP/Y3i7/xP3kCgKDAMVa5Q57SUJW6FeTRqUNTlRfeqBScwK21
n/lKRnc1LR3S/bPB+je+TDGnKNqXxgBOdkReHXT6VlOPRHBqmr0OeZUgMRPmR6rx
d2pnz+0hJkjJ5mQc3Qx2X8fhEe5wWvsX+L5XT0+BIFmbohGzXkoar4sdlopSLO/q
88VuudkkAeP1USE0PfGPjhi1S9yvVFPalSSgAvOVlT7Ho/DpZJxA7ZPkmLHyt709
DDUSoNRRB4M5LLh2DREOUPHNz+rMtK1ETMzSgmEHP+x1TaF1Dplh1Kh9uL+M75ox
ptdpcjDy6W5iyeFSLYk69V/rJxHUTaVbcddfVolvEvUrg6JSzkjJbyNf4V5LvCgy
2katS4gOSdLiB3q6TLhv1q8WqWqPQcfObb71Yq+k//ltKxgOZqKdhLavIiBQ3lSI
DieWpNIazDH4ikuFIbSjLJKHyPjc2kXIfca276wp18tKhYyZD6nf5d52jq1HhNf8
vGiDGOR0OnEOiJzjZsUVU5Pmjaf60j/BEGRMTBuqNgAzhlob7hA=
=wFwP
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZlZDbw3dZgmthQkS%40itl-email.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Apr 23, 2024 at 02:24:09PM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Apr 23, 2024 at 11:47:42AM -, qubist wrote: > > I see this (essential lines only): > > > > # Only primary (4K) screen connected: > > > > user@dom0:~ > xrandr > > DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y > > axis) 596mm x 335mm > >3840x2160 60.00*+ 29.9824.9924.00 > > > > # Only secondary (2K) screen connected w/ scale 2x2: > > # (note: No idea why the weird dimensions in mm, it's a big screen) > > > > DP-2 connected 3840x2160+0+0 (normal left inverted right x axis y axis) > > 16mm x 9mm > >1920x1080 60.00* 50.0059.9424.0023.98 > > > > # Both, side by side, 4K primary, 2K secondary w/ scale 2x2: > > > > DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y > > axis) 596mm x 335mm > >3840x2160 60.00*+ 29.9824.9924.00 > >... > > DP-2 connected 3840x2160+3840+1080 (normal left inverted right x axis y > > axis) 16mm x 9mm > >1920x1080 60.00* 50.0059.9424.0023.98 > > > > > > What is the formula? > > (3840 + 3840) * 2160 * 4 / 1024 > > And even easier, you should have a top line in xrandr output with > "current ... x ..." - that's the total size you are after. > > > P.S. > > > > FWIW, the secondary (2K) screen is connected via HDMI, however xrandr > > always shows HDMI-1 and HDMI-2 as disconnected and "thinks" the > > secondary screen is on DP-2 (while there is only one physical > > DisplayPort). No idea if this is a bug or even related in any way. > > It's probably related how those connectors are routed, maybe there is > some internal converter. But could be also mislabeled outputs in the > driver. At least Intel GPUs only support DisplayPort. Those that have HDMI outputs have a protocol converter. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYoOz0ACgkQsoi1X/+c IsEEhhAAsAvkG1j9TGZtH7Mi31Rf0nwuerC1A6c+gtMOgdylKzhsDiZK6xtu4VRS oDlyHcn/cLAlHVyUYD0Al0Viq5TIgm7VbIKFDVe+wBkg0snCPSgBRr8Glk2lBxCL 2Q1fl118FefAZMdbf58D0GJXylEccxlwOZgbimOkMIFDGUetMSP1o6uGJe8/ElLh JSpPAXkmTTE3gt67k7dU9dJ1DGkDBTmIz3O/MKg7xgUQ8ahqjQzrgcC48Hm8cSda KK4+m/3Ht/BcMfr7X6HZGZnVu01vMgQUV9YE+pK8yqAcKWYYycMOSjZ9BbfZoNCc 5tDMgGoR+F674BiJyqkh9FbnP08xt0AI8nXN9cyjQ9cgvXtuK8gFRoj6qJgUFjYy BEKda0ACwMTarQqomLj+HX2CMO/RWgt7hTqAx4RlY8Z30KbdvUApOLQOGkeiLo/+ CkFijoMSnMrKVbTPqLI9c1CIOX7lijQKzThEJYhVWxrvKnr/+1Go2HgW/JcSb/QO 58Qhg6D9NFPXO1HT+F/NtWpFb30s8GmTz4B5QhyY5UTfi9GmM2/w8AtDcG8v9B6s +n3200wOxVwn+4Hjnc9CmVXpWgs/6aHuKq6sxTL/NIG1fw7imF51l6FrSog3+EsP J6jdnYLapzDGFT3fOt0XBB51uHX4Dr/fTYPs73s/+fMNAEH2UFc= =zg/0 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zig7PZm1ROa_Xp-O%40itl-email.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, Apr 06, 2024 at 01:29:06AM +0200, Marek Marczykowski-Górecki wrote:
> On Fri, Apr 05, 2024 at 02:16:32PM -0400, Demi Marie Obenour wrote:
> > On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki wrote:
> > > On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote:
> > > > Should an empty service argument (qubes.Service+) always be the same as
> > > > no argument at all (qubes.Service)? Right now, they are the same when
> > > > coming from a VM, but not when coming from dom0: qubes.Service from dom0
> > > > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+
> > > > will.
> > >
> > > I'd say they should behave the same - the "qubes.Service" call should
> > > search for /etc/qubes-rpc/qubes.Service+ first.
> >
> > Is the "qubes.Service" call actually valid to make? dom0 certainly
> > makes such calls right now, but I'm wondering if that is a bug.
>
> That's a very good question. The argument (including "+") used to be
> completely optional, and we did distinguished "no argument" from "empty
> argument" in some places. But it was confusing (especially when writing
> policy for such cases) and was removed in R4.0 for VM-originating calls.
> For dom0-originating calls, policy concern doesn't apply, as those
> aren't going through it. But for consistency it might be a good idea to
> always include "+" anyway.
I'm inclined to agree.
> > In that
> > case, dom0 should be fixed to always include the "+". That can be done
> > in either Python (easy, but requires changing multiple callers) or in
> > qrexec-client itself.
>
> I'd say it's safer to change in Python. qrexec-client normally doesn't
> parse the command it sends, and changing the command there may lead to
> some unintended side effects or bugs. But also changing there would make
> it quite hard to make some exception if turned out necessary.
> On the Python side, it isn't that many places - one in core-admin, one
> in core-admin-client and one in core-qrexec. Plus a few in various
> tests. There are also not that many manual qrexec-client calls, I see
> them in app-linux-input-proxy and gui-daemon.
Changing it in qrexec-client turned out to be quite easy, but it also
raises concerns about the same command being parsed different ways (due
to e.g. version skew), and so I decided to not go that route. It also
indeed makes an exception impossible to add without some sort of
out-of-band signalling, such as a new command-line option.
> Anyway, technically this is an API change and as such I'd avoid doing it
> as R4.2 update. Linux agent should have no issue with this, but other
> implementations may. For example I see qubes-mirage-firewall is looking
> for "QUBESRPC qubes.SetDateTime dom0" explicitly:
> https://github.com/mirage/qubes-mirage-firewall/blob/main/command.ml#L25
By "this", do you mean changing the API calls made by dom0 to include
the "+", or changing the way the Linux agent interprets calls that do
not include the "+"?
> > Also, should socket-based services receive what was actually sent
> > ("qubes.Service") or what was used for lookup ("qubes.Service+")? The
> > same goes for executable services and the QREXEC_SERVICE_FULL_NAME
> > environment variable. Right now I fix up QREXEC_SERVICE_FULL_NAME but
> > not the metadata passed to socket-based services.
>
> I'd say socket-based services should receive what was actually sent.
That makes sense, and is actually simpler to implement. What about
QREXEC_SERVICE_FULL_NAME? That's the analog for executable services.
By analogy to socket-based services, it makes sense to pass what was
actually sent here too, but I currently add a trailing "+" if none is
present.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYQlpUACgkQsoi1X/+c
IsHoUg/7B2ZBotLyXRL6teNFabpvDYmprficx8aYURWS/vUIyN/xuCdHBipHFeXi
x9Dl5vsPrrL/+2FAaTGd0dfe8/wc4b7nsev04ynUYTUZ0w5wTnLgA5yABrpct9Hl
TBHoIx6AfWrEZ6RzdPQaCnkjDveuTTSrblpRJ2AKi5CA1BJaQg3HHNL3+75akg8R
KFk0xFyVAcHyeF54FzCokdUcXbecY7LqXvZ0c1LttcAcn1vnBFPuwcUxFc5stIJk
cUOOmOcOAj+NRnPQyYfnbkDNTLVxuvCMmkyrmPJbiVoruHp9NRXIObpG+lI21bHs
rj6eeYM+XakP7wYc38uJC3UmevlPkj2+ctyZc9h9cfLVs0wL4N2uImHPlnvQKTmR
Fz8jCu68D3EHkcXZhqtc8PcVoSq8iR8wgzr4SoMIAlsZTDX0ZgbdGhxuIBSSvtb0
rr0ji8DaT5hwVUERWLFZChX9fZdjtA2KSkT4tTQHlYdenI+9L+jc0LT4fcZVbj2i
gvBRV6NpiCTTQnuUOxsApNF8Qe7fjMH+Y0BQPfRxdthBlNcIMcgV6qyTwsExfeH1
8DsgqfuA0H++Cs9YeToV5yhPWvYvuQPiSzp9WLZLMXN4aO5gPhoun4JS0J06J0TC
8Fy6pRAcwktir6y+69g68sKLyZz8iaXKi8x
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote:
> > Should an empty service argument (qubes.Service+) always be the same as
> > no argument at all (qubes.Service)? Right now, they are the same when
> > coming from a VM, but not when coming from dom0: qubes.Service from dom0
> > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+
> > will.
>
> I'd say they should behave the same - the "qubes.Service" call should
> search for /etc/qubes-rpc/qubes.Service+ first.
Is the "qubes.Service" call actually valid to make? dom0 certainly
makes such calls right now, but I'm wondering if that is a bug. In that
case, dom0 should be fixed to always include the "+". That can be done
in either Python (easy, but requires changing multiple callers) or in
qrexec-client itself.
Also, should socket-based services receive what was actually sent
("qubes.Service") or what was used for lookup ("qubes.Service+")? The
same goes for executable services and the QREXEC_SERVICE_FULL_NAME
environment variable. Right now I fix up QREXEC_SERVICE_FULL_NAME but
not the metadata passed to socket-based services.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYQQAAACgkQsoi1X/+c
IsEUAQ/+I/7EWXa+5CyP2jlsPYH51zUPksQRMdoa7Vli+Wt7CU+Nu0egfu+bMfU1
dugQIjUAvFom0RkM2Yp1eXngoTPzCbAoikg2NSaD6b4wP9xkCDZXogkPzTnjGuld
6IZV0wuCOSZSEnFbwjWhH2IGYmXUywepy4yNUAx/3RNqelZ3JlF5kK8E1v8nuvOs
QTtHrQ6yDRq5PynMfDkkRpZRSsPS9ySiqgKoVel+Pqe1PJm8woX/KhhpMdx5fsGv
fbCuk4SR3O6qZc8xtvUUQ/kZZ4vR9lLMFkOTdQI0wR+7JKdd4IQwJB1YYqAGhZO+
Y2pergpB7dBkeTht8KyuFUvBFSLjKD66PZV2jll+OMQkAZ7U+0sswL8WykXoiSGr
2BSZsG1o+L9V9u21Ncbawfr7dWUFH8ioO0xmJAQ3SxgrhxyerokfYICa7AR3XGMr
0Rwafl4HQsr7VvNGMYeeJ6CdeX90MxD3XVc2OxBd7b/Ak9nYk7CUoE9en3ez1Db8
fp9j81MYe8udbdgDyUiAuWxBmBeJVN7ykA+sOvBwuo6lw346E67mtBPV6d0BgEcC
lGHmA/FfGon7Ah/hHXqMstlcC8haw9gTZmBZbslwAyxSZTJ8zVKH8Lr4pGj5JbGp
+DK148QVIyOCe50ifxOttqw5GGxC5I7zmHYqlnThZNX7pLWAAPY=
=Qlec
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/ZhBAAAY8Eti6xHYO%40itl-email.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Apr 04, 2024 at 10:43:33PM +0200, Marek Marczykowski-Górecki wrote: > On Thu, Apr 04, 2024 at 03:44:40PM -0400, Demi Marie Obenour wrote: > > Should an empty service argument (qubes.Service+) always be the same as > > no argument at all (qubes.Service)? Right now, they are the same when > > coming from a VM, but not when coming from dom0: qubes.Service from dom0 > > will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+ > > will. > > I'd say they should behave the same - the "qubes.Service" call should > search for /etc/qubes-rpc/qubes.Service+ first. The current code does not do this. I have a test and will write a patch. The fix adds extra complexity, so I would like to fix the code in dom0 to always pass an empty argument instead of no argument. Then the next backwards-incompatible release (R5.0?) can treat a missing argument as an error and refuse to execute the call. If no argument is passed, should QREXEC_SERVICE_FULL_NAME reveal this, or should it include the "+" as if an empty argument was passed? - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYPJXIACgkQsoi1X/+c IsEI4hAA1OlFRwU5DONG/Y3079Z1KlaxprsxZE47ecJ5B3gQ3ZoXPkce6JjemEAn 4etsKwqhZ5JAEnq/Mdal7c4EddQtZHKAQLNNyTQNYxwmLd3fu2/J53d15T2R35s5 ftaXG1y8KQUTdgTzC6mUpQl4Xvo8vzN5h3nbiNJZSMbb/+lseXk+tispfnpTGUCu FqPrsnJIzIT8vRYyBHS36zW0PClSu+GfARkIlIb9vFmK1Cu1CSzv7OWNOQcSUS9r mNasTd7MBoTjXkf33u3m+YqqXMclXRsiK59MzY69jMT5ISXX8IoIqF54ypj4MINT uKNpXzWskr7NJCy4uP8ePATJasLiQYm6Qf7y5DbCtD1/x3eK3lD/EOkV+hwhSbD4 7jwapFz1iuBey+oljVP9WCYEz2gLSOmghUi42JWX7KnXYJmyxGYG/IwDfU77tCrG NRR4mjQKVsOu9qlLrrpAlX60vQZeQnoYoiA5+tiXlsQTHYUX3hW8ELNOm6IaCiaj dMx1tpEUhYwwVUUgd+SCX1ohZrFWuno/jPnqYkwnkdG2ZG62TRIw+Dx0DxVkF7Um IP+0DPuqsjLTpBP0dgRUfTKdACjcjjMVkIXguQ13ggK1KYYKNbZ8JbI8ys6k353o HvpHR+6HVTrwEHEJsjAZT2wESPOkiCPi4WRhwgBi8hKBFe8kDks= =nxaB -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zg8lcpcJ69a8WkGb%40itl-email.
[qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Should an empty service argument (qubes.Service+) always be the same as no argument at all (qubes.Service)? Right now, they are the same when coming from a VM, but not when coming from dom0: qubes.Service from dom0 will not search for /etc/qubes-rpc/qubes.Service+, but qubes.Service+ will. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmYPAycACgkQsoi1X/+c IsEdPRAAzFX1QOAVVRNx3yeWdrBW58IQKb7Jjv8KDpFQyhRjz+yeSooJUrrLIGE5 g3AI22Rz4oS1f0YJRHNP9whOU31iLJXZ2lsDsBlfwVLG6qy/cGejxMWAUImT+mRE iU16oOm+LpJfRGZDVC471RglIA3rUy3ymNqj7jg1O/0AXXlk51lHoNEuX3EJEmh6 gAcYhRVQTJ3GoVJjML1NSjZQVAMtwnLuFt99Z5WNeATv4QB1+FVrp9gN3VuWj1pv mmDnusgyCjxs8LyHJc7OGZ4sJqAB+a6uPySKa1cBTJgfuEPJ9hA8FJix+EmIJWL9 mDCZ2x2mCatQcfzeZwl2/2N/QAm/1O0tc3r2kkmgrybyIXz7UpUAqfZ36gobyE48 1N4LLhyxqzADoOvYu15Aw8T26Lt2zLPBnsVTMEKZUChzin1bx70Rr2omXwxwUajS CRCp/MLN2dlnfCKCYsiEkwuOX8QkVPsUagL6Dk+aru9E2eeDyvdB5n7dE/UeZ6Th 9XAn1rBP+bw0PXyfr3BoXZGWbg1EmMmXkcwPUreF4P5duAZkxjn0BfnNzkzUZ55n jLXFTdLWDHJASzrAj5QnegdLWvIveffpRcP/wWXO3giPgoDOFeZLMEDpwFDkCjv+ GfRNeqNtBEzoHRdB2ESBvfmnwMcZ0Y16hXmw5jK3WwEVNr78bZQ= =f5rG -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Zg8DKHfOFKXySbIV%40itl-email.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sat, Mar 02, 2024 at 01:54:33PM +0100, Marek Marczykowski-Górecki wrote: > On Sat, Mar 02, 2024 at 10:58:26AM +0100, Simon Gaiser wrote: > > Demi Marie Obenour: > > > Is QEMU in dom0 fine if it emulates zero devices? I’m specifically > > > wondering about a configuration in which the only emulated device is a > > > virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support. > > > This might require some QEMU patches to support the extra commands that > > > are needed for blob devices. In this mode, QEMU should be able to run > > > under a strict seccomp allowlist and does not need to interact with the > > > GPU itself. > > > > What would be QEMU doing at all in this case? > > > > If we can isolate it similar (or better) than the current stubdomain > > solution running it in dom0 is certainly an option. > > > > One thing to look at is how the required interface towards Xen looks like > > in this case. AFAIK running QEMU in a Linux sandbox is already supported, > > so that interface is probably already prepared for this case. > > > > How would the normal device emulation required for a HVM work in that > > case? Or are we talking PVH? But the later normally has no QEMU at all, > > so not sure if that would work without major work on the Xen side. > > The thing we want to avoid the most in dom0-based QEMU is emulation of > all the base devices (PCI root complex, chipset, various legacy devices > etc). This is an old code base, and also historically some emulators > were reachable for attacks even if given device was configured to be > disabled (see VENOM bug). Xen supports ioreq servers API where emulator > can manage a specific PCI (or other) device and won't receive > communication directed at other devices at all (so, much less risk of > unintended attack surface). But it needs to be used by that emulator > this way (instead of claiming the whole PCI bus, which is what QEMU does > right now). I believe this means that QEMU in dom0 is not an option right now, even if vhost-user-gpu is employed. Cloud Hypervisor + vhost-user-gpu should work once Cloud Hypervisor is ported to Xen, though, and there has been interest in this from the Cloud Hypervisor side. > This touches another topic - what is needed to have virtio for a VM. > Preferably for a PVH domain (so, without all the emulated legacy > devices). IIUC currently virtio in Xen works with HVM only, right? > There is a vPCI that handles PCI root complex emulation in Xen, and it's > used for PVH dom0. AFAIK this code should allow emulation of individual > PCI devices by separate ioreq servers, without all the legacy stuff, and > also is a prerequisite for PCI passthrough to PVH. But I'm not sure what > is the state of vPCI supporting non-dom0 VMs, and how much work is > still needed for virtio for PVH (and also PCI passthrough for PVH, which > is another thing interesting for us). Or maybe some of it is completed > already? I think it is being worked on, but I’m not sure it is security supported upstream yet. Even if it was, it seems to move a lot of complexity to the most privileged context. Is there a reason to believe Xen’s vPCI is going to be more secure? - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXjZ5EACgkQsoi1X/+c IsETtQ//Rtniw1jUc+GLUPkmNlFtJqHgPScr4AhJ1Z3WiM0Kp8o47IBQIlisgJaK J7KtipWL+UOtls521N804wedn2tNdGSp3tleftm34L63dxC55vMtlot5SqGUqh5K hDXtrkJNcPfd3Kxye2sq/wa9e9pqyQW7UfYUR64MniyuxfbyTBeMd9teZ306rv8D ZIMOItT4lEJQy0kM7SlOsuh+EpMexNkQJf4ntrYW8VnrJ0A+RkYhtrqdiZCUJ2bQ Fnji+Gg6WIgjSWcVRbEEr2BiCAEKl1LJtQjb3j5kLHFcIMkJMshJj+H91X9WbItE /HB1em/hkOttmwbr6WadRDV4nrONXIQTifTF7xfjOB9vzxEo1bX6ZAWcG71pYRBL WTpWt3DW/ajE5KG9fF/wdAnr02YX32GJ43XcUptBPG0xPT2sGaEv5z36pMwxfIu6 vyJ/x2pZoVTAEKXA93dRLHvokvgZXT4uRlJYijSCQJK8SN7HeyuQ4Ktt0ljZ+jL8 jrnjDKjD3jJ4FnpB6UJlJLLK+yoDpbaeL0Ce9Xb2L4wHlW7hYQgZ+C+MyqIpEvwq QJuZ1syvQnBrP0Z+6AjaBRbgr74kR3UFDfiV2oz4nkGwngFP6Nlbaot+35rHh6om wufxkSMhHp3h3LLnysFMj0WJOuy7Um7M7aWXASWAPD/0pPt8HKM= =Tf2x -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeNnkWIET_lYl6v7%40itl-email.
[qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Is QEMU in dom0 fine if it emulates zero devices? I’m specifically wondering about a configuration in which the only emulated device is a virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support. This might require some QEMU patches to support the extra commands that are needed for blob devices. In this mode, QEMU should be able to run under a strict seccomp allowlist and does not need to interact with the GPU itself. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXi1C8ACgkQsoi1X/+c IsGXDxAAr6V6Cbd/+41qFtQhVv4uwKg+Oi25XlaAn047E8pQWxIuyakb+V9bn0P2 TgGsyHNlkH7TfBvgSoKfjDczQNVgglkwAAyNXyXHdOE6QrDjjbMnr8ceBgSeGi+c RNeB7uzEec/iuBhk9CAAVC5qdhIHfnD23mtLqraiBfR87Eu4YoT7VYkP8Ywg2agx Jngj7U0rvTw7DAWdWIZ6hXpnxGLWgZHq2hYAyqdvBG/N+pbDh3hFUtHsHpeLKS4c +FAlUNeKK2i+77pN2U5KpquPD9ZDiR04acYIK6MESnd5nk2qGDpGDGRHlnrI26Rs 77iwMlY4qtjyD52XMRo+GYAmQKeYxAoPJwEKaaVr9WprJq6zzDTGqidqhhuNX6mV oFJzg/0LhqzWeKpbi0RnQeucmTMTnInwRDegIJ0Vatw2MAu0LEhGo2JYzxQCXM/d 5bsw6r6xXx0AwfKj8KUBDdu+wIKb/17opCjIrrd4bsDtN18FYD/kg2YlLwKj+Cam e0aHY+MdRSAlNsIw7EXKeFcsK1/YVhM62ehuugWaYPuIG5Dy5bTeSmyTXh+cSla5 UvQJnm/YcGh2M9xnp617XV32ncuWCLHeJ2Vz+vdb/haHDc8n7qVVZdE0ahmYfnNm T8bKBVOMFo3F1UF8bHeBPwyCnZixgVE/XwkeYT9FSVvv5MU8h1A= =jUUs -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeLUL5bK2PKI3jhN%40itl-email.
Re: [qubes-devel] Admin privileges of a GuiVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Feb 22, 2024 at 04:24:49AM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Feb 19, 2024 at 10:47:45PM +0100, PeakUnshift wrote: > > Hello, > > > > When using a GuiVM, several issues appear regarding permission errors. I > > created a topic on the forum and opened an issue: > > - > > https://forum.qubes-os.org/t/grant-full-admin-privileges-to-sys-gui-sys-gui-gpu/24368 > > - https://github.com/QubesOS/qubes-issues/issues/8934 > > > > My message here is more general about what privileges a GuiVM should have. > > Currently: > > - dom0 is not accessible from sys-gui, but we can CTRL+ALT+F2 to access tty > > or login back to XFCE's dom0 session. > > - there is no way to access dom0 from sys-gui-gpu because the GPU is not > > attached to it. > > > > Then, we need a way to get full admin privileges from the GuiVM: > > - Should we grant full admin privileges to the GuiVM? > > - Should we grand full admin privileges to a dedicated AdminVM? > > - Should we create multiple adminVMs for different tasks, but all together, > > give full privileges? > > - Is it just a question of policies or is there other development needed in > > order to execute dom0 commands from a domU? > > > > I'm aware that the GuiVM is still highly experimental, I try to gather > > information in order to clarify the correct path to follow and thus help > > future contributions. > > Generally, the goal is to have specific qrexec services for everything > that needs dom0 action, and then grant access to those, based on some > sensible policy (in default GuiVM case, user controlling GuiVM is fully > in control, but there can be a case where there is separate management > VM for some tasks). It shouldn't be necessary to access dom0 shell at > all. In the current implementation, several of those services are > missing. We collect them in this project: > https://github.com/orgs/QubesOS/projects/15/views/1 > > So, any missing part should get a ticket that we can add to the project > above. In the meantime, some access to dom0 shell is likely useful - > for sys-gui you found it already, but for sys-gui-gpu probably the > easiest way is to setup something like qubes.VMShell. But remember it > gives sys-gui-gpu unlimited access to dom0 - be careful what you install > in the template for that qube and in the qube itself. I will add that certain parts of the Admin API (such as modifying qrexec policy) can be used to obtain full shell access in dom0. This is by design, but is obviously undesirable in certain situations. Is it possible to have a sys-gui that is powerful enough to be usable, but which is still considered to be strongly isolated from dom0? Or does this require features that have not been implemented? - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXW0JIACgkQsoi1X/+c IsFmew/9H1VajzSyJMoMdIbzid27R6Zxaycw5ePeGppFDtHCgNEZtcJ/+iNhEAye DVASqH9NX4K3/aanzqjZmGXwc3HyB5AhnkdhuJfdsSGb1a3VIDdnp++9xwin3Lvb p3ExBDwu0Dpo8yIspgSB8T6TakuUBdAgYPvsYR+LJ5VbOYA0l6w1StECbJS9Tk2v v0qRhb0XHaBzFmInNpJ2uY+6hjGIlZ2YJXhQ50ecePuNv4pRO0SZFfhOylS39BaW OfNMLbFDUIlbuiuYtrpPsR66Zner0EMd5jbrAY/Hw7SPydOgfiUYOUY9RTIAchRS TPeLQ9im9xQeexForRfA7O5fzXpHoJAbabF596H4M5DH/8+2Is+p//yzk3idnKyJ 0S72CU9o3wvqMkwKlGkaVT2kkConuvKhT/CRi+T/8gZi3Lf/olnKWTS14OGXTVz7 MR9z4wVpuqQyx4iMQl7o8mcZ4cj5sGv6Tw9tWOdWjPH0OvwQILwDyr5L7tW70Vj2 pmoBwaUjcYcJ2+rONNYhd18wSjavOq0OQEC6EcxS1IyUX93LV/GjK6/S6voIYGek idJjXpzrfmhOqQ/nC+EtigoclMln+iRQ3I97/t0iqCCUpQAHztt2LrVzGdbLEgFH qgHszeCZp0VoQ5UbuNi7y6evG65FcupEgJ9xCToj8VZPmQS105k= =YXXj -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZdbQkgGb1ACIxs-I%40itl-email.
[qubes-devel] Re: [RFC] initoverlayfs - a scalable initial filesystem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Dec 11, 2023 at 05:03:13PM +, Eric Curtin wrote: > On Mon, 11 Dec 2023 at 16:36, Demi Marie Obenour > wrote: > > > > On Mon, Dec 11, 2023 at 10:57:58AM +0100, Lennart Poettering wrote: > > > On Fr, 08.12.23 17:59, Eric Curtin (ecur...@redhat.com) wrote: > > > > > > > Here is the boot sequence with initoverlayfs integrated, the > > > > mini-initramfs contains just enough to get storage drivers loaded and > > > > storage devices initialized. storage-init is a process that is not > > > > designed to replace init, it does just enough to initialize storage > > > > (performs a targeted udev trigger on storage), switches to > > > > initoverlayfs as root and then executes init. > > > > > > > > ``` > > > > fw -> bootloader -> kernel -> mini-initramfs -> initoverlayfs -> rootfs > > > > > > > > fw -> bootloader -> kernel -> storage-init -> init -> > > > > ``` > > > > > > I am not sure I follow what these chains are supposed to mean? Why are > > > there two lines? > > > > > > So, I generally would agree that the current initrd scheme is not > > > ideal, and we have been discussing better approaches. But I am not > > > sure your approach really is useful on generic systems for two > > > reasons: > > > > > > 1. no security model? you need to authenticate your initrd in > > >2023. There's no execuse to not doing that anymore these days. Not > > >in automotive, and not anywhere else really. > > > > > > 2. no way to deal with complex storage? i.e. people use FDE, want to > > >unlock their root disks with TPM2 and similar things. People use > > >RAID, LVM, and all that mess. > > > > > > Actually the above are kinda the same problem in a way: you need > > > complex storage, but if you need that you kinda need udev, and > > > services, and then also systemd and all that other stuff, and that's > > > why the system works like the system works right now. > > > > > > Whenever you devise a system like yours by cutting corners, and > > > declaring that you don't want TPM, you don't want signed initrds, you > > > don't want to support weird storage, you just solve your problem in a > > > very specific way, ignoring the big picture. Which is OK, *if* you can > > > actually really work without all that and are willing to maintain the > > > solution for your specific problem only. > > > > > > As I understand you are trying to solve multiple problems at once > > > here, and I think one should start with figuring out clearly what > > > those are before trying to address them, maybe without compromising on > > > security. So my guess is you want to address the following: > > > > > > 1. You don't want the whole big initrd to be read off disk on every > > >boot, but only the parts of it that are actually needed. > > > > > > 2. You don't want the whole big initrd to be fully decompressed on every > > >boot, but only the parts of it that are actually needed. > > > > > > 3. You want to share data between root fs and initrd > > > > > > 4. You want to save some boot time by not bringing up an init system > > >in the initrd once, then tearing it down again, and starting it > > >again from the root fs. > > > > > > For the items listed above I think you can find different solutions > > > which do not necessarily compromise security as much. > > > > > > So, in the list above you could address the latter three like this: > > > > > > 2. Use an erofs rather than a packed cpio as initrd. Make the boot > > >loader load the erofs into contigous memory, then use memmap=X!Y on > > >the kernel cmdline to synthesize a block device from that, which > > >you then mount directly (without any initrd) via > > >root=/dev/pmem0. This means yout boot loader will still load the > > >whole image into memory, but only decompress the bits actually > > >neeed. (It also has some other nice benefits I like, such as an > > >immutable rootfs, which tmpfs-based initrds don't have.) > > > > > > 3. Simply never transition to the root fs, don't marke the initrds in > > >systemd's eyes as an initrd (specifically: don't add an > > >/etc/initrd-release file to it). Inste
[qubes-devel] Re: [RFC] initoverlayfs - a scalable initial filesystem
generic solution to this > is hard. My current thinking for this could be something like this, > covering the UEFI world: support sticking a DDI for the main initrd in > the ESP. The ESP is per definition unencrypted and unauthenticated, > but otherwise relatively well defined, i.e. known to be vfat and > discoverable via UUID on a GPT disk. So: build a minimal > single-process initrd into the kernel (i.e. UKI) that has exactly the > storage to find a DDI on the ESP, and set it up. i.e. vfat+erofs fs > drivers, and dm-verity. Then have a PID 1 that does exactly enough to > jump into the rootfs stored in the ESP. That latter then has proper > file system drivers, storage drivers, crypto stack, and can unlock the > real root. This would still be a pretty specific solution to one set > of devices though, as it could not cover network boots (i.e. where > there is just no ESP to boot from), but I think this could be kept > relatively close, as the logic in that case could just fall back into > loading the DDI that normally would still in the ESP fully into > memory. I don't think this is "a pretty specific solution to one set of devices" _at all_. To the contrary, it is _exactly_ what I want to see desktop systems moving to in the future. It solves the problem of large firmware images. It solves the problem of device-specific configuration, because one can use a file on the EFI system partition that is read by userspace and either treated as untrusted or TPM-signed. It means that one have a complete set of recovery tools in the event of a problem, rather than being limited to whatever one can squeese into an initramfs. One can even include a full GUI stack (with accessibility support!), rather than just Plymouth. For Qubes OS, one can include enough of the Xen and Qubes toolstack to even launch virtual machines, allowing the use of USB devices and networking for recovery purposes. It even means that one can use a FIDO2 token to unlock the hard drive without a USB stack on the host. And because the initramfs _only_ needs to load the boot extension volume, it can be very, _very_ small, which works great with using Linux as a coreboot payload. The only problem I can see that this does not solve is network boot, but that is very much a niche use case when compared to the millions of Fedora or Debian desktop installs, or even the tens of thousands of Qubes OS installs. Furthermore, I would _much_ rather network boot be handled by userspace and kexec, rather than the closed source UEFI network stack. It does require some care when upgrading, as the dm-verity image and the UKI cannot both be updated atomically, but one can solve that by first writing the new dm-verity image to a separate location. The UKI will try both both the old and new locations for the dm-verity image and rename the new image over the old one on success. The wrong image will simply fail to mount as its root hash will be wrong. This even allows Apple-esque boot policies to be implemented on commodity hardware, provided that the system firmware is sufficiently hardened. It won't be as good as what Apple does, but it will be a huge win from what is possible today. > (If you are focussing on systems lacking UEFI, then replace the word > "ESP" in the above with a similar concept, i.e. a well discoverable, > unauthenticated relatively simple file system, such as vfat). > > Anyway, I can't tell you how to solve your specific problems, but if > there's one thing I'd suggest you to keep in mind then it's the > security angle, i.e. keep in mind from the beginning how > authentication of every component of your process shall work, how > unatteneded disk encryption shall operate and how measurement shall > work. Security must be built into things from the beginning, not be > added as an afterthought. As a Qubes OS developer and a security researcher, thank you. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZXc4t8ayumo-dhul%40itl-email. signature.asc Description: PGP signature
Re: [qubes-devel] [PATCH] parser: Change warning of invalid path to error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, May 26, 2023 at 03:15:22PM +, Ben Grande wrote: > This was bugging me because in fact should be an error, not ignored. > -- > Benjamin Grande FYI, Google Groups mangles the message, invalidating the signature. I recommend sending the patch inline and using cleartext signatures. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmRw42UACgkQsoi1X/+c IsGHBhAAkR7SYIjmtlxs1qNtZn+sO1QadpSdb+iL1slYaA4SihH9pzdUeHV8vpGZ UOJBYXxDeaHOFLrPSCV5FE9vz23YuNneefJInUoPa8H1U6+f18DS0M6ji5XL7E9Z huQ7XKfJL0ius5/Rwe37evSTiphlLssSxYd7D+lbiRPlmoDkDTBOQK/LTKXyFTeZ 7ZVFiaLED7lVcCQR4SL+6l8MOBeHaFn93FNpj+RZang2w0oNfvTQblDEe8sPFXx1 SVDgMuaEI8toeIriiWoYPVk9EfyszVYZtLh5O+F6vBPRxh9dxBRFFcvmw5nN7/C/ IPwdBbGdBecFhQcr9MQkT6EE3BaOUhqqP8j2EgczScReQ0sYsfKNZRJU1mKZNTBv 2kMa4C/LjTLSvN0ft0RVesb7OcFmns40N0JzyGxdgHxKflSCkCAimIplD/Vtkb3j PDz+6299n4wDASMWHxZwErNCU0kk+jJUstDx2p/eiT5kbSbojt8FRJRzoywFWYFT yw4FzEd2sjEIt2XqWqj32x69vsJZcqxFUlV3OAX+RTDiF+cc1fFiUZ0Xxf8LH11A B9Ope4A4VQJ5BTSvA/LRJLONNG4AKC9omaQf0BxTJg7jpT3X266XyJAthspmCkoA fNPJeyEXIHgUeasBPCmIv4+MTdCb8klaZi8xNb/Lgl5WpD7GTIs= =kOdC -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZHDjZIkBwYfi0WI5%40itl-email.
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, May 25, 2023 at 10:54:48AM +, Ben Grande wrote: > On 23-05-24 14:57:12, Demi Marie Obenour wrote: > > On Wed, May 24, 2023 at 11:53:51AM +, Ben Grande wrote: > > > Contrary to what doc/package-contributions says to do a brief > > > description, I prefer a long explanation than having to answer questions > > > in future mails when I could have answered them upfront. > > > > I like this approach :). Thanks for the contribution! > > Thanks for the review. > > > > I saw that Marta Marczykowska-Gorecka is doing the a GUI application > > > called qubes-policy-editor. I can't deny it has a better usability for > > > people not used to terminal applications but it doesn't work for > > > headless dom0, or embedding the policy syntax into fenced code blocks in > > > Markdown or Rst. Because the syntax also can be used in fenced code > > > blocks, people who edit the Qrexec Policy documentation will have the > > > benefit of getting the syntax inline (g:markdown_fenced_languages). In > > > the end, the user will choose what suits him best, I am just providing > > > an alternative. > > > > Nice! This does mean that the syntax file needs to be secure against > > maliciously crafted policy. It looks like there are some dynamically > > generated regular expressions that could be replaced with stridx() and > > string slicing. Otherwise, the code looks to be pretty good: there are > > no calls to execute() or system(), and the code doesn’t open any files > > with paths that are determined by the policy. > > About being secure against a maliciously crafted policy, normally, the > best thing is to open the policy without a modeline. > ```sh > vim -c "setlocal nomodeline ft=qrexecpolicy spell" malicious.policy > ``` > The option 'nomodeline' is set in $VIMRUNTIME/ftplugin/mail.vim with the > following comment: > ```vim > " Don't use modelines in e-mail messages, avoid trojan horses and nasty > " "jokes" (e.g., setting 'textwidth' to 5). > setlocal nomodeline > ``` > > The downside is that the filetype will not be set by the modeline when > using a policy that is not in the expected path (ftdetect). So using > ```qrexecpolicy > # vim: ft=qrexecpolicy > # My custom policy > !compat-4.0 > ``` > wouldn't work if the path to policy is /tmp/custom.policy for example. > > Currently, modeline is not disabled, it uses Vim's or user settings, > which defaults to enabled. > > Can you please point to the dynamically generated regular expression? > My understanding is that dynamically generated regular expressions > requires the execute command: > https://github.com/vim/vim/blob/master/runtime/syntax/yaml.vim#L146 =~ interprets its RHS as a regular expression, so any VimScript that uses =~ with a non-constant RHS needs to ensure that the RHS is not controlled by an attacker. In your case it appears that e.g. subscripting and stridx() would be better. > It has some nice uses cases to avoid code repetition and using variables > to keep regex, but I didn't do that for vim-qrexec. > > The only file read is the current buffer during code completion > autoload/qrexeccomplete.vim - getline(). Which Vim has already read so > it can show you its contents, now it is read to be saved to a variable. > > > > Dependencies > > > - Vim version 8.2: stable version for Dom0 Fedora 32 and Debian 11 > > > > Do later versions work as well? > > Tested now on Fedora 37, Vim 9.0. It worked. > No complaints about spell file compiled on an older version (8.2), and > the spell file worked. Maybe Vim's error E770 appears only when Vim does > breaking changes to the spell file. > > Vim has history of avoiding breaking changes, so I assumed it will > continue working for later versions. But it still makes sense to use a > postinstall to recompile the spell file when Vim is updated. > > > > Syntax > > > -- > > > The syntax highlighting follows Woju's code[0]. > > > > > > The valid highlighting is nice, but the real benefit of using the syntax > > > file is by making it strict: > > > - Validation for every field > > > - No field can exist without a group > > > - Requires minimum field number to be reached > > > - Shows clearly where the error is > > > - Items of the 2nd field and beyond are always contained and only > > > matched by 'syntax match' option 'nextgroup='. > > > > That is awesome! > > Thanks, this is a thank you letter to the Qubes Team. Also a way to > mitigat
[qubes-devel] Re: Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
On 5/24/23 08:44, Zdenek Kabelac wrote: > Dne 20. 05. 23 v 22:43 Demi Marie Obenour napsal(a): >> I noticed that by default, Qubes OS has voluntary kernel preemption >> as opposed to full preemption. I found that enabling full preemption >> (preempt=full on kernel command line) makes the system significantly >> more responsive under heavy I/O load. In particular, if I build a >> kernel in a Qubes OS VM, it significantly degrades responsiveness >> without preempt=full. With preempt=full, the system remains >> responsive. The storage stack used is LVM thin provisioning on LUKS, >> and I have observed significant CPU usage in dom0 kernel threads with >> names that indicate they are related to dm-thin and dm-crypt. >> >> The kernel config used by the Qubes kernel package I use (6.1.28) is >> based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) >> indicated that the same arguments apply to Fedora. Therefore, I am >> asking if Fedora should use full kernel preemption by default. > > > Hi Demi > > > Could you please provide 'dmsetup table' - so we could see how doe your > device stack looks like ? The output of 'dmsetup table' contains all qube names so I would prefer to not post it publicly. The device stack is NVMe -> crypt -> linear -> thin pool -> thin. > Aren't you disabling work-queues on the table line for crypt targets ? The only optional parameter passed to dm_crypt is allow_discards, so presumably no. -- Sincerely, Demi Marie Obenour (she/her/hers) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/40b31e03-1543-9a2a-67b3-2748369b1991%40gmail.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
syntax match' option 'nextgroup='. That is awesome! > Lint > > Wrapper around 'makeprg' with qubes-policy-lint for native method. > If you prefer a third-party plugin, variable for Dispatch and lint > script for ALE is defined. > > Lint catches cases where the syntax would not be a good way to show the > problem. There is no perfect solution anyway, it is not possible to > handle runtime bugs. > > Code completion > --- > When the field has know possible values such as the default arguments, > tokens, resolutions, parameters, it is added by default to the > completion list. > > For those same fields, the list is incremented for every line that > reaches the minimum number of fields. If a rule has a qube called > 'sourcevm' as the source for the rule, the 'sourcevm' will be added to > the list of possible values for source completion. NICE!!! > Spell checking > -- > If you set 'spell', you will benefit by using the plugin spell file as a > secondary good word list, after your primary language. It helps to > reduce the number of false positives spelling errors. Is this handled automatically? > Credits > --- > Wojtek Porczyk for the initial syntax file[0]. > > References > -- > [0] https://github.com/qubesos/qubes-core-qrexec/vim/syntax/qubespolicy.vim > [1] https://github.com/junegunn/vader.vim/issues/221 > > Questions > = > I have a few questions, if you would be kind to answer them: > > 1 - Would QubesOS Team package the vimfiles to for Dom0 and DomUs? > Only Dom0 can lint, as it requires the qubes-qrexec-dom0 to be > installed, but DomUs can greatly benefit from this plugin by using > all of the rest it offers, syntax highlighting, code completion, > spell check. Personally I don’t see any reason not to ship them. What would be needed to support linting outside of dom0? > 1.1 - Is VimScript a barrier for inclusion as it greatly decreases the > chances of someone reviewing it? Total lines of code excluding > comments, empty lines or lines that multi-lines: 957, as of > 2023-04-15, first draft of this e-mail. I am not personally proficient in VimScript, but IIUC syntax files are largely declarative, which should help. > 1.2 - How can I help reviewers? I documented the code via comments and > the usage via the help file. Is there anything that I could clarify > further? Don't hesitate to ask questions. > > 2 - There is one binary and only because Vim requires the spell file > to be compiled, it is at spell/qrexec.ascii.add.spl. Information on > how to generate the file is documented at spell/qrexec.ascii.add, > scripting the compilation is possible so you don't depend on me. It > may vary on different Vim versions and must be compiled with the > same version that is gonna later be used by the users else Vim will > throw an error. Simplest option would be to build it in an postinstall script and use a trigger to make sure that it gets updated when the Vim package is updated. > 3 - What is the recommended style for indentation? Tabs? Spaces? > Textwidth? I made some assumptions based on the current files > shipped by Qubes. Tabs are expanded to spaces and indentation is > made as 2 (two) spaces. Textwidth is set at 78 for comments, leaving > 2 columns for the sign column or line number. Rules are wrapped, > they do not break with the textwidth, but comments break after > textwdith for uniformity. Please search the code for > 'g:qrexec_recommended_style' to suggest changes. Qubes OS uses 4 spaces for indentation in C and Python, but I am not sure what the standard is for VimScript. > Note I am not proficient in VimScript, I learned through the examples at > $VIMRUNTIME, so code review is highly appreciated. > > Code is never complete, tasks can be found by searching for "TODO:". > > Packaging > = > Currently, there is a Vim syntax file at qubes-core-qrexec repository, > but it is not installed to Dom0. If Qubes Team decides to package the > plugin, I recommend using the path > /usr/share/vim/vimfiles/pack/qubes/start/vim-qrexec, to keep the > plugin files together, organized, instead of dispersed. A package names > "vim-qrexec" would be a meaningful name and easy to search for. > > Furthermore, I didn't put the build files of qubes-skeleton in place > because I am waiting for the acceptance of this proposal, if it is going > to qubes-core-qrexec, if it is going to stay as a separate repository, > if it is going to become a contributed package or denied the inclusion. > > There are no automated tests as I haven't found a suitable framework, > therefore tests
[qubes-devel] Should Fedora switch to full kernel preemption (CONFIG_PREEMPT=y)?
I noticed that by default, Qubes OS has voluntary kernel preemption as opposed to full preemption. I found that enabling full preemption (preempt=full on kernel command line) makes the system significantly more responsive under heavy I/O load. In particular, if I build a kernel in a Qubes OS VM, it significantly degrades responsiveness without preempt=full. With preempt=full, the system remains responsive. The storage stack used is LVM thin provisioning on LUKS, and I have observed significant CPU usage in dom0 kernel threads with names that indicate they are related to dm-thin and dm-crypt. The kernel config used by the Qubes kernel package I use (6.1.28) is based on Fedora 37’s config, and Marek Marczykowski-Górecki (CCd) indicated that the same arguments apply to Fedora. Therefore, I am asking if Fedora should use full kernel preemption by default. -- Sincerely, Demi Marie Obenour (she/her/hers) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/fe4ecb3e-c620-20ae-a79c-a6cd664f1357%40gmail.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[qubes-devel] Thin pool CoW latency
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Like Eric, I am very concerned about CoW latency and throughput. I am almost certain that allocating new blocks and snapshot copy-on-write are _the_ hot paths in Qubes OS. In particular, I suspect that workloads such as building an image in a throwaway VM or installing packages onto a root volume that had just been shapshotted are dominated by metadata operations, rather than by in-place updates. I suspect that frequently-snapshotted volumes will observe similar behavior in general. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmQE/iEACgkQsoi1X/+c IsHLFxAAyWT4SlSueR15VxrwG07T9cEl7vnQwKHKWdzFBoWl0KhvyjLr52t0ip1J HPmwTVaor+53E+0bLUlgqA7G56a6PwxWWAQ6CsHHdxQ1xo3Serigkhys2hmwRq+e WPVrDSVRQLzOj/Qg6MsF2PPzdL5aNjK2QeHnWVcyXvfwZDhDCJKzz2iJC/ENjFNW X2bD3wazu6A+aFsxjLHtf5wAa0+PhppcEhUZNSgQiC9SiT5DPFabLIIi7jgb0Nlg v5GciAp1w0J+SUq2Wh4atrPR11Sj878AnJ872/Ku+pLseVu8h7N/60p8OwBm47Ak GNZlgq7XF1lien/3eFq9mfJKGc97MxveEkiqI46ankVs+bDQOlUbXriMlINEeT8r AzCar8pYx5W/xFb/gvYPnksATlOxLAaQ1jPZ1j0dIRaPtoOngtQ64TC5alRirGCK uqQ7c1Soj7D3SjahrbQkoqcyODmRoC/55Pu8Klb2l96S91rSRtvca+EV05GNXmyN eaArdGNuWPmzq6E8mQj3YrYnn18Z/x3WRr77xGVTAjUCGDPCE01+o/0G9P/+4cpv olMs1/ludL/WzbBe9scp2JK442dGwE/pcBiWI34DmxbLZTb1baG4BEX6mbDdfnpk SmIQv1RcHtbf16nvuhg+QVXnjAL5qQNiGVWxF9PTH8799wmcsdM= =/KY9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZAT%2BIoCfuZtRnnhm%40itl-email.
Re: [qubes-devel] FreeBSD Jails for QubesOS isolation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, Mar 03, 2023 at 01:41:56PM +0100, Keno Goertz wrote: > Hello everyone, > > I'm writing because I'm interested to work on FreeBSD jails as an > alternative to Xen for isolation in QubesOS. And I have some questions > about it, that someone on this list can maybe find the time to answer. > > I recently learned about FreeBSD's jails, which provide isolation > similar to a chroot environment, but with proper virtualization of the > file system, the set of users and the networking subsystem. > > https://docs.freebsd.org/en/books/handbook/jails/ > > I've also read about Joanna's vision of Qubes air here. > > https://www.qubes-os.org/news/2018/01/22/qubes-air/ > > Joanna argues that using Xen to achieve the separation is not really at > the essence of Qubes, and she shows how the cloud or seperate raspberry > Pis could also be used for this purpose in a future version of Qubes. Indeed it is not. > Along the same train of thought, it should be possible to build on top > of FreeBSD's jails, right? It absolutely should be. > This is something that I would have interest > in doing some work on, perhaps as part of my master thesis. My main > motivation is to have a version of QubesOS with lower overhead on the > virtualization technology. I'm aware that there may be differences in > the protection offered for e.g. attacks on speculative execution between > using Xen or FreeBSD's jails for the isolation. There are two major limitations: 1. FreeBSD is a monolithic kernel, so jails do nothing to sandbox device drivers or the Wi-Fi or USB protocol stacks. One can use PCI pass-through with bhyve or (you guessed it) Xen, though. 2. The not-very-hardened FreeBSD kernel has much more attack surface than the Xen hypervisor. To somewhat mitigate this, I recommend: - Considering HardenedBSD vs FreeBSD. - Using a non-vnet jail inside a vnet jail, with the non-vnet jail not allowed to create other jails. This avoids some of the nasty problems with non-vnet jails without allowing the code in the jail to reconfigure the jail’s own networking stack. - Using strict devfs rulesets that only allow access to a bare minimum of devices. - Denying as many privileges from the jail’s root as is practical. - Using a kernel compiled without e.g. COMPAT_FREEBSD32. - Disabling support for protocols such as SCTP. > So I don't think one > technology would make the other useless, but rather that they would be > two options to choose from depending on the threat model. It could also be useful for testing purposes. FreeBSD has sufficient Xen support to allow one to port the existing tools for Xen-based Qubes to it. Therefore, this would allow one to run jail-based Qubes in Xen-based Qubes, with much lower overhead than nested virtualization (which Xen doesn’t support anyway). Right now, if one wants run the Qubes integration tests, one must use a seperate test machine, which is rather annoying. A jail-based Qubes would allow one to run them from within a qube on the machine one is working on. BTW, FreeBSD can run under Xen as either a dom0 or domU. A good first step might be to implement a FreeBSD template for Xen-based Qubes. That would both be useful in its own right and be a good way to get familiar with the Qubes codebase. > My question is: Is it actually possible to start building this by > implementing the things described under "Under the hood: qubes' > interfaces" in the "Qubes Air" blogpost for FreeBSD jails? Or is there > something missing from the side of QubesOS that first needs some work? > Or do you think this is a stupid idea to begin with? :P It’s not a stupid idea at all! It should definitely be possible, but you might run into various parts of Qubes OS that assume Xen+Linux even though they do not need to. High-quality patches to fix those are welcome. I am also CCing Mariusz Zaborski (aka oshogbo) who is a FreeBSD developer himself and knows way more about FreeBSD than I probably ever will. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmQCoIUACgkQsoi1X/+c IsFC6g//fW7mvNqN1dAwWj8stluV2UAy6hmUHc246fbqtugtsACWZVe8ha8fDPmm h5TiMQI23YzbgE0S/Y7jieLCWks+PF9hY+QJdceNSAFxlNeDXjokWsfRvf3PkcQD HOp3wrQsklx4mHjiSMf/HkLypSKdeOAVA9nqECC8xZWvCiBGdkGeBXFpWy/R08WY ChhCK6FmlK7fE93w009p/hxdcwJfFMK6vLIwpywsz/PEo+ifrujzt/LB50kHIhWW 8VWqhNisLi9uJzCEkK5XhO26QlLQlJqokz5+dxFz79mpNLUu8WjFp+uaF1femDAq jKtl+eZZIjOLyJg8m9nn81yYWqUl6sdCa9Qeo5uEm/zwBrRhQ0RF3PnFQ6Rb7Tao K/tZpQloikWxZdIsVBDtXswqD00LTB0MKFP5rRQWXgyfDRnJLpeuIxa5kwhaWAe6 dJGaYokVN+CFKO4eamjv9ccHJ0slWzqqdpM4M7eqamvs7+85EWlmGyv5ImL/mnV5 qmssnkFZF/Pn2Xo1kGY2PsewIltqLWW2ZenyOsPKHorcUt2lNGjL/hsXixRX0z7S KT1VnUXjm/+GTC3l2/l96ZXWMT+6QaTwbyn
Re: [qubes-devel] Qubes is compatible with Gnome (A report & request)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Dec 22, 2022 at 05:11:40PM -0800, Howard Chen (HowardPlayzOfAdmin Gaming) wrote: > To the Devs: > > As you may see, Qubes is compatible with Gnome desktop; however, it does > not have Qubes settings icons in it may be because it's only works with > XFCE and KDE. As in the image, everything is working fine, but the images > of Qubes settings are missing. I have some questions: could you guys make a > gnome-shell extension so that Qubes can be compatible with Gnome DE and > with workspace ease adding module within the extension? Thanks. So far, the Qubes developers have been reluctant to add GNOME support. There are a few reasons for this: - - GNOME Shell extensions have an unstable API. This is not a problem with GNOME in dom0 because the version of GNOME Shell is frozen there, but is a significant problem if a GUI qube is used: if the extension misbehaves, either no window will appear (making the system useless) or colored borders will not be drawn properly (a security vulnerability). - - Significant parts of GNOME Shell, such as the integration with NetworkManager, are unusable in an offline GUI qube. The Evolution integration could theoretically be used, but it would be limited to local calendars only. Reimplementing in a way that works for Qubes OS would require more extensions, which again runs into the lack of a stable extension API. - - GNOME Shell does not support tray icons at all. The intended replacement (notifications) is not supported by Qubes OS. However, there is an extension that does provide support for tray icons. More generally, GNOME is a very opinionated desktop environment. This clashes with Qubes OS, which is (of necessity) also very opinionated. KDE and XFCE, on the other hand, have much better support for the high degree of customization that Qubes OS requires, which makes them better suited for Qubes in general. That said, none of the obstacles are insurmountable, and I believe GNOME support would be a good candidate for a contrib package. I at least would be willing to review PRs to other parts of Qubes (such as the GUI daemon) that make GNOME support easier, though the final decision is Marek’s. If anyone is interested in implementing this, feel free to ask questions on qubes-devel. I cannot help with the GNOME-specific parts, but I can answer questions about the Qubes-specific parts. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmOnpxkACgkQsoi1X/+c IsENKRAAopYcoZ6l6XW0XDnkeZOhC3XnLVoj+N4c9aREcBJG41VENaSLDDWv16Ni 4dPDFM0g1W2acMfR68lRIbrzcgt0h2pogXKy9QP0szu9ixKvXaSHRelyDi/Nsf7n AMYjtjnyLF0yVioy9mchebbr+eV2dN/mkZD81dbbwGiS2f8x8Hrrolw5WnmWWU9w bFHnJXbg6RYtozo8OCUkLe5A4oxqWl0N0Zg6mRxOYivRaXuxuMM52wTOBkUwQsS4 gPkKEfPYeSY3WfAR88/5TqSTUv+jzr/jXrBe02YIdrn5lTDrZ34ETDreew+87rHr T9GD8xuPAIBD/UcYj5yK5U+bADmPSJIudKcYFXBh6S4C4oCpyJfOqERM0KZBRgw0 S2Bax2YJU0xuPw+gCjWtraXrWiEdKeoMf6CRFIjS1D3DcSSW0o4U1Ojk+CZVeSm5 nsA6Sh4xf71MFvHUlkpgtiOihV/97X45TpxsWu+K6n4t8S9KPPADewxcWqZ2kJR0 uj5WifAY7EzCmePtr4hgnG3hPcHPWyeU3PHiK8/vbWbCVhRMxVzftqNgQNBL8MW8 4EKaTODSQj/pBnqk/ElxFYVMYOiQDfIh0ji+RsBKjJoaqgJ0joxZjwjC08YqdfsT bAyAKc2jZRqTd3yOOHiQkiWOE+z3uT6sCK5ffbE/HIjjcrpvw2U= =3erX -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y6enGV/V7BkFNO1c%40itl-email.
Re: [qubes-devel] Proper bash completion for Qubes OS commands (mostly qvm-)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sat, Dec 17, 2022 at 08:30:31AM +0100, Qubes OS Development Mailing List
wrote:
> Hi all,
>
> I would like to contribute to the Qubes OS project by making proper
> bash-completion of Qubes OS commands (primary for qvm-* commands).
> The related issue: https://github.com/QubesOS/qubes-issues/issues/7887
>
> Before doing something I analyzed the existing solutions - mostly this two:
> https://github.com/jgriffiths/qubes-completion/blob/master/qvm_completion.sh
> https://github.com/Qubes-Community/Contents/blob/master/code/productivity/qvm-cmds-bash-completion.bash
>
> And while both of these solutions are interesting, have different features
> and ideas, they still have major drawbacks and do not fit my high
> expectations.
> I would like to make a better one, taking ideas from these two and best
> practices from bash completion of other GNU/Linux tools.
> I would want the new completion to be as clever, advanced and comfortable to
> use as possible.
>
> To achieve it I hope some of devs could answer some technical questions I
> have.
> Starting with these:
>
> 1) I see some inconsistencies in `man qvm-clone` maybe because it was
> generated automatically. So, which one is the proper syntax:
> `--pool POOL_NAME:VOLUME_NAME` or
> `--pool=POOL_NAME:VOLUME_NAME`?
> Or both are allowed?
> The same for `--property` - must it follow with = sign or not?
Both are allowed in both cases.
> 2) Are names of qubes allowed to start from "-" (I really hope not).
Qube names must match the POSIX Extended Regular Expression
^[A-Za-z][A-Za-z0-9_-]{0,30}$. Therefore, qube names must not start
with ‘-’. However, your code should be robust against ‘qvm-ls --raw’
and friends returning names that do start with a ‘-’.
> 3) What do *-chars in `--property NAME*=*VALUE` mean?
That the man page has a bug. Please report it.
> 4) Are options really allowed only before VMs's names in commands like
> `qvm-clone` (the `man qvm-clone` says so)?
> I would like to respect this strictness in completion to provide the best
> completion experience possible.
I recommend assuming that they are.
> 5) Is `man qvm-create` broken in the first paragraph of Synopsis? It has
> `qvm-create` the second time on the same line (last one) of the first
> paragraph.
> The `qvm-create --help` does not provide information about the second way of
> calling:
> $ qvm-create --help-classes
I believe the man page is correct here.
> Bash completion for sure should take all valid options into account.
>
> 6) What name would be recommended for this completion in case it goes to
> qubes packages?
> I think something like generic `qubes-bash-completion`or `qubes-completion`
> is fine, but different people make different names for it. So, maybe you have
> opinion on that too.
I prefer ‘qubes-completion’, as this may be extended to support other
shells in the future.
> 7) Will it be possible and is it desired to add these completions to the
> default Qubes OS packaging system to give them to users out of the box?
That is up to Marek, but I would support it.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmOk3sQACgkQsoi1X/+c
IsGlNBAAsYc7HmhG+lS/DP0Z1Jk+3Lbwa9qb6+5Jfr7rx3ADaZyAH76VaaOSGGSS
xinDx3gJyT0D15SQuQxZInL0A0uauYI5huxbkuS9VAw5437Gq2wMp6mdd2KeilQL
5GyE508SzI+50v/brt8s9TUG8CQLpyZg9TUwhOPcUZVLXIWuS37ymRUd4Hpklu27
5hId5wfRtmw+lcj09RS0SuLUyCkLPhCFxLjB+1V8LU01Oiq1m21etCmtNbwdkXa2
O1J1qx/ALVYNK4J3A+wmA15nwD8v7wuiDcQS/XtH3EJgx1yBkAHbx53QKHJjW7oQ
wnor5QmsuS2xT2ec76Oi8E6AyfqKFCW6j2gW/Yr/KJeyxRINAQrkZHEyzxap3ll4
XxsycSt1H0nWVDuSjL6Y6Z9g+4Y8WufQKQJEvhi9KO/LsAZ9l/qIzyehRl0KScPL
j6AtNkSlKTadNkGYy4bJJAG0MlGxYaxD9TQ2s71gFKLKnZ5cCEqFon+Ic35uDpbJ
rj8aKmA3jRGo2wa4EikPIFQIJcVHfkHt57FaLHBOFs9eb0R9NG6KZABbaRH4gS4i
N94/mNmtRr5Y0wvXZ0uR5lLe6BTqRQuveE43hWgGucefk/ypIUSwRaSPZhhtuRxS
FmGtvLgHyMjLoufNoXKNuJqO9KMLvBnrglthT4ZJwXnLtenvO3I=
=f0EN
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/Y6TexXkfPNC0uXJ9%40itl-email.
Re: [qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, Nov 29, 2022 at 04:54:51PM +0100, Marek Marczykowski-Górecki wrote: > On Mon, Nov 28, 2022 at 01:40:31AM -0500, Demi Marie Obenour wrote: > > On Mon, Nov 28, 2022 at 04:02:50AM +0100, Marek Marczykowski-Górecki wrote: > > > Hello, > > > > > > Since some time already, new repositories in QubesOS github org had > > > 'main' as default branch. I've just switched default branch to 'main' > > > for existing repositories too. > > > For transitional period, both 'master' and 'main' branches will exist, > > > and will be kept in sync (there is a bot for that). So, all repo clones, > > > builder.conf files etc should remain valid. Existing pull requests > > > should remain unaffected too. > > > My current plan is to keep this transitional period at least until R4.1 > > > EOL. The reasoning is that any existing build/devel environment for > > > R4.1 should remain functional as long as R4.1 is supported. But any new > > > environment for R4.2 should use new branch names already. > > > Example R4.2's builder.conf qubes-builder (v1) is updated already. The > > > one for qubes-builderv2 will be updated shortly. > > > > Does not work for me: > > > > -> Updating sources for builder-github... > > --> Fetching from origin main... > > fatal: couldn't find remote ref main > > make: *** [Makefile:224: builder-github.get-sources] Error 1 > > I went through repos list again, hopefully haven't missed anything > important this time... Another error: -> Updating sources for python-xcffib... --> Fetching from origin main... --> Verifying tags... ---> No tag pointing at 09c10f07c1e0bfd8ee1248f887e2b1f2f274be08 ---> 09c10f07c1e0bfd8ee1248f887e2b1f2f274be08 is a commit signed by a trusted key ― did the signer forget to add a tag? Also linux-yum’s main branch is behind master (by two commits). - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmOGjOYACgkQsoi1X/+c IsFsahAAmx0Fl+D7N1Hing+lbXmB+TMombEj4XCUUgTgHdCgccXEoGat6hZGVUs6 nxcUVYrYhIWjZE2CVtMJf9V8Dn03PCxnBOsoJnpypqaD5g0fPgukOPHRSHUubhbM XB83KuucOzcMrXLAb+oLDJaima7zu8LK+4kCXpkUtX57ddXoivYnEmVXhrEhBoXZ VoE2FMQjavP518awcJ8jjXEaUzXTWr/MEbmEYFLPjUSCcu/CK3R3tBlzXZEkNPsx vhk6IJ/eb4B1NCe+qHZwF3yNFl7G8g7QWnvosQS/t1wR8pP9KOBdM+6k0MtJIsfh RPsHQUnCuvQkmlHUnGJFJlXyl5KW7yrT66HuyA7YTpJh36vQWdUfVZNNJCBacxlT Fv/sm7DY1Spm1zWpUreNZtBQ9ibXxMupSF26MfkyviGpaCc3H1Ah06bW6oQS5T1f AdbbAyeWCe7UwUkB0LpzUEz1NfF18geNQDb9tlDY2uwdWPYzjseSt8E3UtvhC5Xj dHwj0uHj9a3fArfb8BPVLt6G+EynDj6cJfEhdxdGE0bB9e6R7wCD7ERU5rtIfdKt LXwHyOwe8karjInAZo9teG8DOU/VrchWX/LlnrBqLPJLcIzUD9egpHEgOTspzxMQ J0CgDRaYR47ht+gYF1JuqweXD5VpGWB1NTAfkHi9IW7CSbrcxXI= =8JuE -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y4aM5f42%2BPnho1Xs%40itl-email.
Re: [qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Mon, Nov 28, 2022 at 04:02:50AM +0100, Marek Marczykowski-Górecki wrote: > Hello, > > Since some time already, new repositories in QubesOS github org had > 'main' as default branch. I've just switched default branch to 'main' > for existing repositories too. > For transitional period, both 'master' and 'main' branches will exist, > and will be kept in sync (there is a bot for that). So, all repo clones, > builder.conf files etc should remain valid. Existing pull requests > should remain unaffected too. > My current plan is to keep this transitional period at least until R4.1 > EOL. The reasoning is that any existing build/devel environment for > R4.1 should remain functional as long as R4.1 is supported. But any new > environment for R4.2 should use new branch names already. > Example R4.2's builder.conf qubes-builder (v1) is updated already. The > one for qubes-builderv2 will be updated shortly. Does not work for me: -> Updating sources for builder-github... --> Fetching from origin main... fatal: couldn't find remote ref main make: *** [Makefile:224: builder-github.get-sources] Error 1 - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmOEV98ACgkQsoi1X/+c IsG9kQ//QhmUNVmJ+eiuse86Gz6hR8b66ZedtWTr6IxJ/aggwmnslc7pedROBsrz 18ZbNvill/GOtJMzMx7895SoSc1BlYVkKONhshQC3FGmySF6mU8+VOTDaUCU/te2 5iRUkMw8ItfBKkw7eCKwXea4tB2PITI4CTjmB1dUedNR0VcDCjAetb3Moss3zzmG OQNX/2BGqQUZc3J5rCGCgI1YSf5hkkGUfSvbb4SLdrglQd2urMWI59zq0oCyaGAZ Q9z8q2A4kC8yy8y3bdStTMOfgdDN5NSpykjQRc9sYiE3zt7zHhZEUCIJP4YJPH19 uY+6k4P7XqS+0YKpBnceXYdyuhvTjNoqJgcnd1Dkb6L9A58bPnvmBMERrWj1QZ2h PvO5uCAlgYPaktsVj0pruxhINOHx6hmoC+LEFvYm51Y10WlMx+wzC1aTT2W3enV7 bNRN7SL/Wl4UzErKjlit/JATxkvqQSa4NuVY/GzSic1zZmsD0TQZV8Qc4O2fU77f Lnx+B4FdgVU8ZAfZwu/nhDOi3Zxws0B4B51jbRVIe4MjscMQyOB36Nys1j5jR7up BBsKzMQrq1B5hah7E94a4hkdZNZPWh7t6vOd4aUP1wODTwI+KM3XDOOq46QW+NYM jVmkAJtstbb1+8oIbl5GDqDVJReZ2/BQ9hNGCUW9uAAVRTqXykk= =PDde -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Y4RX37Xdomp6PeUW%40itl-email.
[qubes-devel] Re: [PATCH for-4.17?] x86: support data operand independent timing mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Sep 15, 2022 at 01:56:06PM +0100, Julien Grall wrote: > Hi Demi, > > On 15/09/2022 12:24, Demi Marie Obenour wrote: > > On Thu, Sep 15, 2022 at 12:04:55PM +0200, Jan Beulich wrote: > > > [1] specifies a long list of instructions which are intended to exhibit > > > timing behavior independent of the data they operate on. On certain > > > hardware this independence is optional, controlled by a bit in a new > > > MSR. Provide a command line option to control the mode Xen and its > > > guests are to operate in, with a build time control over the default. > > > Longer term we may want to allow guests to control this. > > > > > Since Arm64 supposedly also has such a control, put command line option > > > and Kconfig control in common files. > > > > > [1] > > > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html > > > > > Requested-by: Demi Marie Obenour > > > Signed-off-by: Jan Beulich > > > > Thanks for the patch, Jan! > > > > > This may be viewed as a new feature, and hence be too late for 4.17. It > > > may, however, also be viewed as security relevant, which is why I'd like > > > to propose to at least consider it. > > > > I consider it security relevant indeed, which is why I was so insistent > > on it. Whether it is worth a full XSA is up to the Xen Security Team. > > If it could be backported to stable releases, that would be great. > > > > Marek, Simon, would you consider backporting this to R4.1? > > > > > Slightly RFC, in particular for whether the Kconfig option should > > > default to Y or N. > > > > I think it should default to Y as long as guests do not have the ability > > to control this. > > This raises two questions: > 1) What is the performance impact to turn this on by default? I am looking > for actual numbers. I do not have access to such hardware and so cannot provide such numbers. I was hoping that someone else would be able to do the needed benchmarking. > 2) What happen on HW that doesn't support DIT? Are we going to mark them as > unsupported? The relevant text in Intel’s documentation is: > For Intel® Core™ family processors based on microarchitectures before > Ice Lake and Intel Atom® family processors based on microarchitectures > before Gracemont that do not enumerate IA32_UARCH_MISC_CTL, developers > may assume that the instructions listed here operate as if DOITM is > enabled. > > Intel Core family processors based on Ice Lake and later, such as > Tiger Lake, Lakefield, and Rocket Lake will enumerate DOITM. Intel > Atom processors based on Gracemont and later will also enumerate > DOITM. Refer to the Enumeration and Architectural MSRs section for > more information. In other words, no action is needed (or possible) on CPUs that do not enumerate DOITM. CPUs that do enumerate DOITM require it to be explicitly enabled by for cryptographic code to be secure. This was a poor design decision on Intel’s part, which might be why it appears that Linux will treat DOITM as a CPU bug. > > Otherwise any cryptographic code in the guests thinks > > it is constant time when it may not be. > > Why would a guest think that? Are we telling the guest DIT is supported but > doesn't honour it? Xen is telling guests that DOITM is not required for constant-time operation of cryptographic code, even though the hardware actually requires it. Furthermore, Xen does not allow guests to set DOITM. > If yes, then I would argue that we should clear that bit. Otherwise... Xen actually needs to *set* that bit, not clear it. > > Once guests have the ability to > > control this I would be open to reconsidering this. > > ... this will introduce a problem once we expose it to the guest because we > cannot change the global default as some user my start to rely on it on the > default. I would be fine with requiring the toolstack to opt-out from the safe default. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMjNDYACgkQsoi1X/+c IsEi+RAAskGqEC1ParSsfyWS7fw9mhKzH+pS+IsKE5tjCu1l6Ctub17qqysC3Oej yzqMPuK+YwwEW5X3SNlnd6Qs5C/2XIdkr8cwB8PitjMabS1dvJu01qIRbIyMDM2i ii9qtuTLCDUAz5rrLW+qr0TE9vBcfteOKzkcWkmQQpWjermZHy+lHooXNmwjS9oc J+nGbUWhNy1uNvFA+sUjEcEucAlSyM7UWkL/c9FzfWV2UwPWppdGpyz7jrRdZT+H brb3FwRd1hoS4t94Xv9ynzZ9K7KeEZ5pF8rKOoKh0cfZ9Ydcuh0wr9dtD6aWTS3r I2rNQig6AqurCF6AVUIlwf6TYcI71BRNDB3SQNAh7h5yxjy1S0srE0RLIZXFiboz 0RAyq76NFWS9qN2BG11PvfaG665EL14+7I+xaJxeS
[qubes-devel] Re: [PATCH for-4.17?] x86: support data operand independent timing mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Sep 15, 2022 at 12:04:55PM +0200, Jan Beulich wrote: > [1] specifies a long list of instructions which are intended to exhibit > timing behavior independent of the data they operate on. On certain > hardware this independence is optional, controlled by a bit in a new > MSR. Provide a command line option to control the mode Xen and its > guests are to operate in, with a build time control over the default. > Longer term we may want to allow guests to control this. > > Since Arm64 supposedly also has such a control, put command line option > and Kconfig control in common files. > > [1] > https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html > > Requested-by: Demi Marie Obenour > Signed-off-by: Jan Beulich Thanks for the patch, Jan! > This may be viewed as a new feature, and hence be too late for 4.17. It > may, however, also be viewed as security relevant, which is why I'd like > to propose to at least consider it. I consider it security relevant indeed, which is why I was so insistent on it. Whether it is worth a full XSA is up to the Xen Security Team. If it could be backported to stable releases, that would be great. Marek, Simon, would you consider backporting this to R4.1? > Slightly RFC, in particular for whether the Kconfig option should > default to Y or N. I think it should default to Y as long as guests do not have the ability to control this. Otherwise any cryptographic code in the guests thinks it is constant time when it may not be. Once guests have the ability to control this I would be open to reconsidering this. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMjC4MACgkQsoi1X/+c IsELUg//fTRCauj/woVL8a3NpcB/2T2/gM06Lhg/eT7DsW4aJEIinB+jZ1mQ4oUb MWEe3Ljwo0bxhbWbbQt2Xqp0pRM1MsDT7D0Boe0qEbpFYCgs8NrRvNE+MrtXG24x B+2E/KZBIesjLV26S3uWTItHfUiFbqo5xzJURCDNHZqZiDnvCs4adiCMNDfroXyL 4UnP1slglrL/x/WqU9VKsWOOJAHTId2cBFd5FDlCQ7UX/GQISUIk7NZqCvutbtny nJpSlbYoUcuQ3IfB4S7zDE4sN2YatCDqojZsAYuwRCRCRgM4nmZJUvK5KwzR1k6Z 0DfvZ0R4h5gdSrylqABzteEwLbob2icXxY89QHhssh/737R0HE5sRK2HKOPRZgUz bmdlismQMqAuzUceAFreIGoPsIQUongF2xZJIY6AtGLudvaB8GZVyeJCgvH/eYyA N05zybw3brLDgTjLN+HXTtsH4X7t4/ktCbGCLZWUytu5h4tr/wg/IXhd84uCu88n 3oLHLuqtpJUNItDYSmLSNQ7KO3Py4pbGjV7ienUl4fGpLS9MKG6raCTj12xO5nq8 5C/vMuzCRiJF3lEvHOrkVjH7vANk/8pfnqoHoMHs4lM2QnlskdOsjCPa17ZZWHs0 knT9OrN4hL7GgA2aU33rfhvgtDq6p7n5Xg2+YbNAbj7lSydjSho= =dfry -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YyMLg7KbeOT1MMpH%40itl-email.
Re: [qubes-devel] qubes-mirage-firewall template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Aug 31, 2022 at 08:58:57PM +0200, Joe wrote: > On 8/31/22 12:10, alain pierre wrote: > > Some qubes-mirage-firewall users ask the mirage team to be able to install > > it as a template with qubes-dom0-update. Do you think this could be > > something that would be valuable for Qubes users? > > > > I'm obviously biased, but very much in favor of this being an > easily-installable component. > > This firewall reduces the risk of routing-related problems (QSB-056 comes to > mind), and crucially the reduced RAM usage is a real game changer. > > I for one hope we can get this going :-) > > Joe I hope so too, and I would like it to become fast enough to be the default. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmMP2nAACgkQsoi1X/+c IsEISxAAxkjNWXds2utvpXvbSC5A5dvqwR2yB5ETUyezuZbf78//8B+uqBJBWBet VTNhgj26dfDKmbzOiCdCwQScMe/L8YHcpH3tG4aO0GuoFs/w2wgIGmV4lGqAq2L6 Q+FRkJGbqq0vLGF+qdk0AIHSh6jFy2zoY0qgmFhXlqDaznkfP0xyypbbwpXatkYU HDeyK6kGdKi6z9P/Z15Qv6uSXImluespQxv2EW2yYfLeMzCM9LNSG1am+7Rl2z0e 8MqnSCNHs+wMdbVowjZ6+KavVmnpb6neHpAypc3yCfmcv84rRtsYnLzH/IF4e6E2 8oS8ImDXUQLNJLhdW4LXAsdmjHqyT++ioqhiVKWJJBUrKn/rgp7u+UXwSiyz9dQT AXaQmkPlp5IPHEDlZbGmDUeTC3/ppFWII9wgA7jhPiEXXJZZMNgl4brewLylnk0r 1NdQJd7FJsOuE1PjSARCYy+8uzLbN+91CJ+8I+QS2ePFg11hb4T0fgA0AWg5r4hn wLKlBXjioNx738TjkSoZY6kYIUYwV9sAa7HqPBioXmNFHMS9OQWleKsKePWZQ8PV gBwMn4p2Ie3E8Oqw7GqtWbv833ul6WolOBsAP1R4MdFT4oTQpSJzj3XR910NssH/ D5AKO2+8SSQCw3C/4pM04Mur1ge+9XaYQo2GJYQOC8jsRbKL7Vk= =y8WR -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Yw/abzY89C9DDK/i%40itl-email.
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Jul 20, 2022 at 03:34:24AM +0200, Marek Marczykowski-Górecki wrote: > On Tue, Jul 19, 2022 at 07:40:00PM -0400, Demi Marie Obenour wrote: > > On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > > > This indeed makes migration easier, and is exactly the thing we should > > > recommend. I think we should adjust defaults to make the scenario > > > described earlier unlikely to happen by mistake. > > > > > > What about something like this: > > > 1. Make default gpg homedir for split-gpg2 backend something else than > > > ~/.gnupg. > > > 2. In the migration guide include step to generate subkey for signing > > > (the one for encryption should be already there). > > > 3. In the migration guide include step like: > > > gpg --export-secret-subkeys | gpg --homedir > > > /default/split-gpg2/gpghome --import > > > 4. Maybe even consider an option (default enabled, but possible to > > > disable) that does the step 3 automatically. Either if the split-gpg2 > > > homedir doesn't exist or if secret keys in the default keyring are newer > > > than in split-gpg2's. > > > > > > I'm not sure about the last point - it may make key management a bit > > > easier (for example for those preferring to create new subkeys instead > > > of extending expiration of existing ones). But on the other hand, one > > > still need to move public part around(*), so it doesn't eliminate all the > > > manual steps... > > > > Moving the public part around can be semi-automated, as you suggest. > > Generating the subkey is also easy if the key is stored in software, and > > it might even be possible to write a script to do it. > > > > The main problem is smart card support. OpenPGP smart cards typically > > have three key slots: one for signing, one for decryption, and the third > > for authentication (often SSH). If all three slots are in use, it will > > not be possible to generate or use the subkey on the card. Generating > > the key in software would work, but it loses the advantages of the smart > > card. > > That's a valid point. But also, if you have a smart card, you have > already more or less the functionality of split-gpg2 there. The main > difference being a confirmation prompt, but some security keys provide > this too. So, there is little (not zero, but little) point in combining > split-gpg2 with a smart card. IMO the main use of split-gpg with a smart card is to avoid having to expose the smart card to the (untrusted) frontend VM, which might try to do nasty things to or with it. This is especially true for YubiKeys and other multi-function devices. > And also, you can avoid the issue > discussed here the very same way - by having separate card with just > subkey(s) - instead of just separate homedirs. > In short - I wouldn't worry about slots availability too much. It is > something we should probably document in the migration guide, together > with workarounds (separate offline storage/card for the primary key, or > software storage for some subkey). > If many users will be affected by this limitation (and unable/unwilling > to use workaround), we may consider some alternative solution. But I > kind of suspect it won't be necessary. > > > To work around this problem, I think we could provide a split-gpg1 > > variant that only supports a subset of safe operations. > > --list-keys, --list-secret-keys, --export, and --sign (with hex UIDs) > > should be safe. --encrypt should also be safe, but it is not very > > useful without the (unwanted) --import. That said, these operations > > should enough for Thunderbird, which does encryption internally. > > Decryption can be handled via split-gpg2, with filtering to prevent > > attempts to decrypt with a signing key. Attempts to perform operations > > that the split-gpg1 subset does not allow would be handled via > > split-gpg2, by exec’ing GnuPG directly with the appropriate sockets set > > up. > > "should enough for Thunderbird" - that's exactly the thinking that got > us to the current situation with split-gpg1. Even if a static set of > options will be enough for all the future versions of TB (which I highly > doubt), there are other applications that users expect to work too. Note > the main issue about options filtering is not about the main command > options, but all the auxiliary options. Thunderbird is a special case for two reasons: - - It uses gpgme, which only uses a small subset of the possible options. - - It only performs private key operations with GnuPG,
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Jul 13, 2022 at 03:35:46PM +0200, Marek Marczykowski-Górecki wrote: > On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote: > > [ Sorry for the previous mail with broken white space, hopefully fixed > > now. Really annoying that Google Groups still prevents using PGP/MIME. ] > > > > Demi Marie Obenour: > > > split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has > > > several advantages, such as much lower attack surface, support for all > > > of gpg(1)’s options, and support for key management operations. > > > However, the last is also a potential security concern. > > > > > > Right now, a compromised frontend VM can sign or decrypt messages with > > > any key in the backend VM, but it *cannot* sign or revoke keys. This > > > limitation is also useful, since a mail client (for example) has no > > > need to perform these operations. However it is difficult for > > > split-gpg2 to enforce this restriction. > > > > > > The technical reason for this restriction is that the “type” byte in > > > an OpenPGP signature of a message is always 0 or 1, but other > > > signatures use different types. The type of a signature is part of > > > the signed data, so it is not possible to pretend that a signature of > > > one type is a signature of another type. The type of a signature that > > > GnuPG will generate depends on the options passed to it, but > > > split-gpg1 only allows a subset of these options. The subset of > > > options passed by split-gpg1 only allow signatures of type 0 or 1 to > > > be created, and those are only valid as signatures of messages. > > > > > > Unfortunately, split-gpg2 does not see the data being signed! It only > > > sees the hash of that data. Therefore, split-gpg2 has no idea what > > > type of signature it is making: it could be a signature on a binary > > > document, a signature of a key and user ID, or even something that is > > > not an OpenPGP signature at all. For instance, gpgsm also uses > > > gpg-agent, and so is also supported by split-gpg2. It generates CMS > > > (Cryptographic Message Syntax, also known as S/MIME) signatures, which > > > are different than OpenPGP signatures. > > > > Correct. You need to think of split-gpg2 as a smartcard (that has one > > acknowledge button). There are indeed things that are not possible with > > the splt-gpg2 architecture that are possible with split-gpg1, for > > example showing the data you are about to sign (only useful in a few > > cases). > > > > For such special cases I would recommend to use neither split-gpg > > variants and instead use a dedicated qrexec service that just does the > > needed operations. This also makes other things like for example an > > audit log much easier. Of course you loose the "gpg drop-in" feature of > > both split-gpg variants. > > > > > The best solution that I have come up with is to not allow the > > > frontend to use any key it wishes, but only allow it to use a subset > > > of keys. > > > > Exactly! > > > > > Migrating from split-gpg1 to split-gpg2 would involve generating a > > > subkey that is capable of signing data, but is *not* capable of > > > certification (signing other keys, revoking keys, etc). split-gpg2 > > > would then be configured to only allow the frontend to use this > > > subkey, *not* the main key. The frontend could still generate > > > signatures of other keys with this subkey, but these signatures are > > > not valid. If a program trusts these signatures, then either it has > > > imported a key controlled by the frontend (in which case the frontend > > > could have just generated its own key) or the program has a security > > > vulnerability. > > My primary concern is a case like this: > 1. Somebody either uses split-gpg1 or simply wants to protect their > private keys from being extracted and used without authorization. > 2. With split-gpg2, an attacker controlling client VM can generate own > key and get it signed with your primary key. > 3. They can then push new subkeys to some keyserver to have them > distributed. > > At this point, it isn't that helpful that you still control your primary > key, attacker have a subkey they fully control and you may be not even > aware of that. If they manage the key distribution part, nobody else > will see anything suspicious. > > > > Sadly, split-gpg2 does not have support for this
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Wed, Jul 13, 2022 at 01:56:54PM +0200, Simon Gaiser wrote: > [ Sorry for the previous mail with broken white space, hopefully fixed > now. Really annoying that Google Groups still prevents using PGP/MIME. ] Yeah, *especially* when one wants to attach files. > Demi Marie Obenour: > > split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has > > several advantages, such as much lower attack surface, support for all > > of gpg(1)’s options, and support for key management operations. > > However, the last is also a potential security concern. > > > > Right now, a compromised frontend VM can sign or decrypt messages with > > any key in the backend VM, but it *cannot* sign or revoke keys. This > > limitation is also useful, since a mail client (for example) has no > > need to perform these operations. However it is difficult for > > split-gpg2 to enforce this restriction. > > > > The technical reason for this restriction is that the “type” byte in > > an OpenPGP signature of a message is always 0 or 1, but other > > signatures use different types. The type of a signature is part of > > the signed data, so it is not possible to pretend that a signature of > > one type is a signature of another type. The type of a signature that > > GnuPG will generate depends on the options passed to it, but > > split-gpg1 only allows a subset of these options. The subset of > > options passed by split-gpg1 only allow signatures of type 0 or 1 to > > be created, and those are only valid as signatures of messages. > > > > Unfortunately, split-gpg2 does not see the data being signed! It only > > sees the hash of that data. Therefore, split-gpg2 has no idea what > > type of signature it is making: it could be a signature on a binary > > document, a signature of a key and user ID, or even something that is > > not an OpenPGP signature at all. For instance, gpgsm also uses > > gpg-agent, and so is also supported by split-gpg2. It generates CMS > > (Cryptographic Message Syntax, also known as S/MIME) signatures, which > > are different than OpenPGP signatures. > > Correct. You need to think of split-gpg2 as a smartcard (that has one > acknowledge button). There are indeed things that are not possible with > the splt-gpg2 architecture that are possible with split-gpg1, for > example showing the data you are about to sign (only useful in a few > cases). In some ways, the situation might actually be worse. I am not sure if a smartcard will allow using a signing key for decryption or visa versa. I know that split-gpg2 will. > For such special cases I would recommend to use neither split-gpg > variants and instead use a dedicated qrexec service that just does the > needed operations. This also makes other things like for example an > audit log much easier. Of course you loose the "gpg drop-in" feature of > both split-gpg variants. I agree. I have just such a service that I use for signing git commits and RPM packages. I should clean it up and publish it at some point. It is only 60 lines of Python, and much of that duplicates what qrexec policy can already do. This *will* require an array of client-side wrapper scripts to adapt various programs, but this can be worked around. The wrapper script used for split-gpg1 might be a basis for some of these. > > The best solution that I have come up with is to not allow the > > frontend to use any key it wishes, but only allow it to use a subset > > of keys. > > Exactly! > > > Migrating from split-gpg1 to split-gpg2 would involve generating a > > subkey that is capable of signing data, but is *not* capable of > > certification (signing other keys, revoking keys, etc). split-gpg2 > > would then be configured to only allow the frontend to use this > > subkey, *not* the main key. The frontend could still generate > > signatures of other keys with this subkey, but these signatures are > > not valid. If a program trusts these signatures, then either it has > > imported a key controlled by the frontend (in which case the frontend > > could have just generated its own key) or the program has a security > > vulnerability. > > > > Sadly, split-gpg2 does not have support for this — yet. There is no > > fundamental reason such support cannot be added, but right now > > split-gpg2 (like split-gpg1) either allows all access or denies all > > access. > > That's not quite true. Yes they don't provide an option to filter keys, > beyond not importing them to your GNUPGHOME (I consider that a feature, > due to reduced complexity). But what you seem to have m
Re: [qubes-devel] Add more desktop environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 10, 2022 at 11:46:29PM +, 51li...@ileg.al wrote: > On 2022-07-10 17:38, Demi Marie Obenour wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Sat, Jul 09, 2022 at 01:01:10PM +0100, Qubes OS Development Mailing > > List wrote: > >> On Fri, Jul 08, 2022 at 04:48:33PM +, 51li...@ileg.al wrote: > >> > Yesterday I tried to make some additional desktop environment that can > >> > be installed during the installation, as far as I know i3 and kde > >> > declared stable by some people. Is it a good idea to add a desktop > >> > environment that we can choose during the installation process? > >> > > >> > I also tried adding gnome and it looks good. > >> > > >> > For the screenshot you may look at here > >> > https://forum.qubes-os.org/t/advanced-qubes-installation-light-installer-4kn-debian-template-detached-header-encrypted-boot-dom0-dispvm-in-tmpfs/11603/5 > >> > >> I'm surprised that you were able to add Gnome - I thought that the > >> consensus was that it would be difficult to incorporate in to a Qubes > >> environment. > > > > That consensus is accurate. I will be adding an entry to the FAQ > > explaining why GNOME integration in Qubes is much more difficult than it > > appears. > > - -- > > Sincerely, > > Demi Marie Obenour (she/her/hers) > > Invisible Things Lab > > -BEGIN PGP SIGNATURE- > > > > iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLLDqIACgkQsoi1X/+c > > IsFCqxAAjWmZ/KWirFJBVnrF1l1RtLXPSPp8qo05/4I0vAtAQzDJkvdj1TgsKlBu > > yFQszTjB6Pp34T20IvMFuXR/V0+DcmnmFgbYaXyzmb36HsFTuEqgSdItIN3yyigR > > 0Sze/80CfehuAiuzutREog+N1OWMJCEt1TTR7RW8ptzUfsry1FwNDkiBd8bRNNRJ > > d3R0336DOM0VqU2iY35T1MXCmen6BmlxYL4tz9KA1hRHQpsjz+uSrfSocTjsz2jv > > +BWdVd4DvLl5N9iiWxttx6qQmH4hPqu9R+mgFfiWXYB1b6uWb/0t26hcMtZHRKWR > > LHlly8AB2ltF17d5yulc5G0CPibrqerjs0lvkVQD0abayj6kjKaKVHSQG/zeJlWp > > 4mQwQ/hbg2e7Pcq7qBxTrnMe/+QoEXbJPgMq72FmaF+9SOAimUJZVj+vj+q1NGhM > > SN4XkQCtcnWBLKezHv8DTJ1k9XVhwt5ZOwgdcIEeMk6vtY7JJyzhqm2Qw4KUel4M > > dWdxWaeOLYTD+A126nc7X4Q2Xg+f2V83dCkCkJGEI9BLO8+mg+wUiDDGb7g5CI2b > > 70Zp/beta/ZwntkguE+xY/IKwF+Atv9oSTh3isrJwQ234yM0H0tWY92b+40Qveq/ > > sRPl6Qx/kNkXCogk/teb1RHE0rOlqUYAgLkT1pvsqy10Ys7SpKU= > > =Ipx9 > > -END PGP SIGNATURE- > > What i found after testing : > 1. There's no screen flickering, my xfce, i3, kde (or official) build > has screen flickering if i use IGPU, until now I always use my 1660ti > (and I believe other user who use modern laptop has this issue too) but > with gnome it's stable. > 2. There's no copy paste global notification but they've worked, every > vm notification like connection, or other notification is work. > 3. There's no sys-net network applet, tor status, and other related > widget in the dom0 panel. > 4. Everything is worked (you can imagine it as a standard developer > daily use) > > I actually have the idea how to solve this, but let's see in couple > days. > Another pict about gnome screenshot, it been tested in my laptop > https://forum.qubes-os.org/t/advanced-qubes-installation-light-installer-4kn-debian-template-detached-header-encrypted-boot-dom0-dispvm-in-tmpfs/11603/6 The two must-have missing features are colored window borders and status icons. The former can be solved (with a significant amount of effort, so do not expect it anytime soon!) by using client-side decorations (decorations drawn by the GUI daemon, not the display server). The latter will require a GNOME Shell extension, which is a problem as those do not have a stable API. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLLbPAACgkQsoi1X/+c IsFacxAA3ZP2ARg8m3jeCDBnltdAygTmqMRxcfZbvSZOArbuyo5EKnc0fm37m5tN hamaae5rs6UBNhm0PKXVeJ9qCxUoaL9Bbt/R5cd0i9f1idOssR6iiZeO2OVPYLhP uBzBVlH/y1Bprl4WRJYBxY43g6faqX9bkCBDMeVQI6RS9ClVYH0jm1ejNoluDTEk MwVfKdw1HsWZlj6VtUXnQ5bTnJjCfeAKCnUrNoFE29ovq5iYzdo24pCPG1QXPYHg fuDWvYy/XydjyH0ZxbZM0FpsAFOA7NY1l/gs3kBzhVEoeNjLFdw3AMRVSKdIYThZ +Vn6Mg2O4CV6s6HFCQ45of/4lmAa6jxvgYx0slf14rM7T1HaxO3rtjILe0A2sXkD k6+guiVZ93ofu79GocgqQSH5i5azj6SmbuO4OXfG3A4JCZlnVfaeFWB/PoSXrq4P D6o0S+3Mhog0iix/Yx25zb0xZZgUpGD5ON6XaX6FPLqdscwhd1iZ4eeXLTkYaGtP k6ptI2Gr+TO65gQHV7l6q+xrKB3SNlozmDUsZuFQQNCjtrJ1d1VQeuGq5wgUgL6T Zp2uTHGCHGWie8K2OxOB6yiMSBGxNA8cTu/PF/C/uj/204lBjq/RIgYFjAqjhkgc 0fldBE505j16Rxbyg2CpYNR2m2NsCIDvy2GrsxqBL1rnRXpl5WE= =+JGm -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/Ysts70BtQqWHxqPi%40itl-email.
Re: [qubes-devel] Add more desktop environment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jul 09, 2022 at 01:01:10PM +0100, Qubes OS Development Mailing List wrote: > On Fri, Jul 08, 2022 at 04:48:33PM +, 51li...@ileg.al wrote: > > Yesterday I tried to make some additional desktop environment that can > > be installed during the installation, as far as I know i3 and kde > > declared stable by some people. Is it a good idea to add a desktop > > environment that we can choose during the installation process? > > > > I also tried adding gnome and it looks good. > > > > For the screenshot you may look at here > > https://forum.qubes-os.org/t/advanced-qubes-installation-light-installer-4kn-debian-template-detached-header-encrypted-boot-dom0-dispvm-in-tmpfs/11603/5 > > I'm surprised that you were able to add Gnome - I thought that the > consensus was that it would be difficult to incorporate in to a Qubes > environment. That consensus is accurate. I will be adding an entry to the FAQ explaining why GNOME integration in Qubes is much more difficult than it appears. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLLDqIACgkQsoi1X/+c IsFCqxAAjWmZ/KWirFJBVnrF1l1RtLXPSPp8qo05/4I0vAtAQzDJkvdj1TgsKlBu yFQszTjB6Pp34T20IvMFuXR/V0+DcmnmFgbYaXyzmb36HsFTuEqgSdItIN3yyigR 0Sze/80CfehuAiuzutREog+N1OWMJCEt1TTR7RW8ptzUfsry1FwNDkiBd8bRNNRJ d3R0336DOM0VqU2iY35T1MXCmen6BmlxYL4tz9KA1hRHQpsjz+uSrfSocTjsz2jv +BWdVd4DvLl5N9iiWxttx6qQmH4hPqu9R+mgFfiWXYB1b6uWb/0t26hcMtZHRKWR LHlly8AB2ltF17d5yulc5G0CPibrqerjs0lvkVQD0abayj6kjKaKVHSQG/zeJlWp 4mQwQ/hbg2e7Pcq7qBxTrnMe/+QoEXbJPgMq72FmaF+9SOAimUJZVj+vj+q1NGhM SN4XkQCtcnWBLKezHv8DTJ1k9XVhwt5ZOwgdcIEeMk6vtY7JJyzhqm2Qw4KUel4M dWdxWaeOLYTD+A126nc7X4Q2Xg+f2V83dCkCkJGEI9BLO8+mg+wUiDDGb7g5CI2b 70Zp/beta/ZwntkguE+xY/IKwF+Atv9oSTh3isrJwQ234yM0H0tWY92b+40Qveq/ sRPl6Qx/kNkXCogk/teb1RHE0rOlqUYAgLkT1pvsqy10Ys7SpKU= =Ipx9 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YssOoZRRo4E/ZVbX%40itl-email.
[qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 split-gpg2 [1] is the planned replacement for split-gpg1 [2]. It has several advantages, such as much lower attack surface, support for all of gpg(1)’s options, and support for key management operations. However, the last is also a potential security concern. Right now, a compromised frontend VM can sign or decrypt messages with any key in the backend VM, but it *cannot* sign or revoke keys. This limitation is also useful, since a mail client (for example) has no need to perform these operations. However it is difficult for split-gpg2 to enforce this restriction. The technical reason for this restriction is that the “type” byte in an OpenPGP signature of a message is always 0 or 1, but other signatures use different types. The type of a signature is part of the signed data, so it is not possible to pretend that a signature of one type is a signature of another type. The type of a signature that GnuPG will generate depends on the options passed to it, but split-gpg1 only allows a subset of these options. The subset of options passed by split-gpg1 only allow signatures of type 0 or 1 to be created, and those are only valid as signatures of messages. Unfortunately, split-gpg2 does not see the data being signed! It only sees the hash of that data. Therefore, split-gpg2 has no idea what type of signature it is making: it could be a signature on a binary document, a signature of a key and user ID, or even something that is not an OpenPGP signature at all. For instance, gpgsm also uses gpg-agent, and so is also supported by split-gpg2. It generates CMS (Cryptographic Message Syntax, also known as S/MIME) signatures, which are different than OpenPGP signatures. The best solution that I have come up with is to not allow the frontend to use any key it wishes, but only allow it to use a subset of keys. Migrating from split-gpg1 to split-gpg2 would involve generating a subkey that is capable of signing data, but is *not* capable of certification (signing other keys, revoking keys, etc). split-gpg2 would then be configured to only allow the frontend to use this subkey, *not* the main key. The frontend could still generate signatures of other keys with this subkey, but these signatures are not valid. If a program trusts these signatures, then either it has imported a key controlled by the frontend (in which case the frontend could have just generated its own key) or the program has a security vulnerability. Sadly, split-gpg2 does not have support for this — yet. There is no fundamental reason such support cannot be added, but right now split-gpg2 (like split-gpg1) either allows all access or denies all access. There are various workarounds, but all of them are more complex than I would like. What are people’s thoughts on this issue? In the short term, one option is to use split-gpg2 as the backend for split-gpg1, which works fine. However, split-gpg1 is a maintenance hog with a lot of attack surface, so migrating entirely to split-gpg2 is definitely preferred. [1]: https://github.com/QubesOS/qubes-app-linux-split-gpg2 [2]: https://github.com/QubesOS/qubes-app-linux-split-gpg - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLA9hgACgkQsoi1X/+c IsE4QQ/+Mrou3OjktLirktp3QsSB6SuINxoY+oSUScecz10SnQkyMORkn+D3xGZq Ed7xa8E1VIpws7KNHrqc01q5jW4OpccZSrHhnI2SMGdNGeo5r4BA+R7+YaSU40g2 iqJ1Blt15nT1QDl+fEwtO8bgWYrMiN5IYOiSKx+vrsBy83qnvWRp8CogO9Zr9JjW Bsg8qrWklsUT3/VCA+9zosBtjXx749NBZpdHMw/kK7ulhHvNrtcSMFDIx8Fyl5XH dMXV8Lj65zF/g70gOck/4EIfVuFzOFo3LmfiVXQgZFmn80q2hJe2Fr3G2N0troG5 V3+vg4+1ed1p3mPVhzZEfYkmBrEqKsma1CVTctmMMPLTdiHGojbjbd+U2zgqHM8w 8K/+aPL3/KCy6h9zIY0/aSyLgDueUfdgvsGwlA9GpumaX3lDjFF6SpnYPgrnysd/ 3bMSwXejSWpNwqIR5zmAllR5l23k1Oz0Y2fRMaHTeMhj/jqn/X9g1nNpCRckFkpu 899ihnmHl+otpyLavRusfctGFmnngBcjNJhIPrXAry5ECioOcIHC38GXX3xuLt30 ss6lNgGrMxQU/6pd89rRWlVGHiC3h6rkHI5v67bcOD9KPWNQEeQADRXYHgc8eDOi e5m7TFF/L1OGmZPwHChP4ae+pSXE7X791vOpnl9d7h3gfYQ3sKo= =wpg3 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YsD2GKbWSzVs8YYE%40itl-email.
Re: [qubes-devel] My notes on Intel 12th Gen on an XPS 13 Plus
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jun 23, 2022 at 08:15:58PM -0700, Dylanger Daly wrote: > Hi All, > > The following is just a little rant about Intel 12th Gen on the Dell XPS 13 > Plus. > > Firstly, I'll list out everything that didn't work (kernel-latest 5.18 > custom compiled ISO) > >- WiFi (AX211) >- GPU (Intel Xe 12th Gen) - Intense level of Artifacting > - This was fixed via sys-gui-gpu, however sys-gui isn't ready to use > yet, battery levels don't show and shutdown control over dom0 isn't > implemented in qrexec yet - updating dom0's linux-firmware package also > didn't help >- Sound (Looked like a firmware signing issue, kernel was complaining >about a missing singed dell firmware package) > > Aside from all of that, it's Intel, personally I really don't like Intel, > if I have to absolutely *have* use the x86_64 ISA, I'll always go with AMD. > > Intel's ME and complexities make me personally uncomfortable, I understand > AMD has it's PSP, AMD seem less complex and more upfront about firmware, > anecdotally. > > I returned the XPS within a day of it arriving and recommend anyone > thinking about getting the latest Dell XPS to refrain from doing so until > > A) Dell drops the weird Intel agreement they have (Where are the AMD XPS > SKUs?) > B) Intel 12th Gen is better supported by Xen and/or Linux Kernel I believe this is not actually a problem with Xen *or* Linux, but rather a problem with Xorg and/or Mesa. If you were using a dom0-provided kernel in sys-gui-gpu, then the kernel would be the same, and I suspect the firmware packages were the same as well. The Xen version is (obviously) the same in both cases too. That means the problem must be in userspace somewhere, and Xorg and Mesa seem like the most likely candidates. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmK1QEIACgkQsoi1X/+c IsGgYA/+Poxu9LXRMB7ZZslZIZDbCaAmrhRS02wIycGSH78lWzYBhelW/0ykxUwI /6MAAgjiTXNC2vhlqgj/Km/Itf1YaoeHJXW9ThvGz3AefuXpqoe3VFw4c1a/3Ic1 SkL1qzv7pJ5DvUVz/KdaMXH+gX4XBGFhTVixVmITgS6TRGnmUhqAl3PMRQ1OdF8j jJwNpj6lRvFvAAVX4FcihpyoigOwXRKtjBiKJ+VLTqdG8VgrzS5kEvCQHSxS5OIa i1fyG20f6rRPB3+VLQCftW31/EQzNQmSBtYqFjuGKV4Mcew3bO2XA3Buf8jyjkLw 3hkCSeuNv9DCRKzDiKUhi184nDIZ6urfXiZrMSWzXLSn/pibJ7APPPLR0LHMKPhN iGobd2+gBipDe6gLdFLgWmlRQQrfoMsa2srcqe9zDBwat1LfcSSYZaSjd3FQFxFt 7hZHyFPrZ8OPOBo1ChJAKN6NAuUtVxcv3Od3euir0wY8oImIS9ZMLVAZOD1g6zPg saEgkjxrGdHd39tAqQ8ZUxFotiqw1jgJRwhr1XxEqEztXYa5Pt81mlHnMBgLktAY KxXvddgjoE60q5UkjOVN3ERbTgnq9enplqnAtOUZgV/9uw2rv0IzwegKmvvVRTx4 zkRuMi7OcVH2+0rCaJuoGfblFq4kvceopNDRxNEywErCRkoYq64= =AKlr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YrVAQ9wcMvuzvpnb%40itl-email.
Re: [qubes-devel] Fully ephemeral DispVM's
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 16, 2022 at 12:34:50AM +, Qubes OS Development Mailing List wrote: > I recently wrote a patch that makes all PVH DispVM's fully ephemeral in the > sense that all writes to the disk are encrypted by an ephemeral encryption > key, with dom0 handling the encryption. > > Currently Qubes implements this (when ephemeral=True and vm:root rw 0) for > data written to xvda and swap but not for data written to xvdb (i.e /rw). > This patch fixes the issue and encrypts ephemerally all data written to disk > from a PVH DispVM. > > This is accomplished by making xvda, xvdb read-only and ephemeral=True the > defaults for DispVM's (three line patching of dispvm.py) and by patching > /init of initramfs of the pvh kernel so that all data writes are routed to > xvdc using dmapper. This routing is already partially accomplished in qubes > by mapping all writes to xvda to dmroot when vm:root rw is set to False. The > patch now routes in addition (when vm:private rw 0) all writes to xvdb to > dmhome and seamlessly relabels in fstab xvdb to dmhome, before /sbin/init is > initialized. The fact that xvda and xvdb are now set to be readonly in > DispVM's and only xvdc is writeable and ephemerally encrypted ensures that no > data escape is possible. > > I wrote a script to implement the patch on a live R4.1 system. It is > available at > > https://github.com/anywaydense/QubesEphemerize > I would be delighted to hear your comments. This is great, thanks! As far as storage is concerned, you can use a thin pool and external-origin snapshots, which might simplify some of the code. You can also use read (a shell builtin) instead of cat in various places. There is a chance that the disposable qube’s /rw and/or / could run out of space, causing I/O errors. With thick snapshots I believe this is fatal and causes all further I/O to fail. Thin snapshots are slightly better and “merely” fail all further writes to unprovisioned blocks. To prevent both problems, one can ensure that the volatile volume has sufficient space allocated to it, but this increases the amount of space the disposable qube could consume so there is a tradeoff. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKqlrMACgkQsoi1X/+c IsHEcBAAw4dDm/kbFUVBncdarFE0bgTl6Wj8omSeKZTM2GXioGqg4DvHjoQ/cASO rEXI9ZKu2tZBQLcFWAYx98AxfXtrq4IESXMY0MziY7qh+JPS/4TN3dHS6sNZnS+3 aLmZq4I4wLrgm1dR+Dr/F1CX1SbjH1ZZvDH5y/lURnDUYX1TF0Zzw6GtSlNEMnlh wiZUwIS19BJP+yVRyEdaR0AWHdpWC8yypN8BeOTAIOJ7sSurywPiKqw77Z3Kg4L5 hZWDpqHfHUFOXzTfkqnOayi6yUpSAQJpIlJKNHT9xSSOGMBML1+xSJqCfY0G1klw 4tWP6XtytJgslg0gpyBU289re0LJWWe6MXygOIFeImqHy+yHMBepG1QS3G3Va2y9 w0jYDvSwpHUdEXOP8on8Afvi0qET4ldw/xCK0/7hLyGm8afgjHAiG/G6tmyrQm8W dxarU6+19SuEJQQdWTpsK/LyV1fdW7468LKdBTEggqZAjGSR4IzhocrN+9GufOaG yktnGliiOqPHc7A+qu06L4VvYyjBj803W8HxdAT6ZcdCeS1qMSBbEpODDmyf1y4U TrmkfdSfo4NOp9o82SS+9vuSrauNE40xXPJqRLVM2hoooeesvX8hdOSFN0hEC/Eg tYL9e7ZPd/iRh8yG7vfi+QCRCbTisSg0wgJRs89yeUbBtPoKry0= =4Qkz -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YqqWs1T3tj7mZRXh%40itl-email.
Re: [qubes-devel] Re: Future certification requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Jun 08, 2022 at 02:22:12AM -0700, Michał Żygowski wrote: > Hi Demi, > > Thank you so much for these requirements. It contains many insights into > how software/firmware can do better. Still, I have some questions and > doubts I wish you could clarify: > > Ad. 1. I find multiple occurrences of the oxymoron "persistent mutable > state" in the 1st point and e.g. 7th. Could you please explain what state > might be mutable and yet persistent? These terms look contradictory to me. “Persistent mutable state” means state that is mutable by the host and which persists across reboots. This is a problem for PCI pass-through, as it allows the VM controlling the passed-through device to tamper with the device, in a way that will not be fixed by rebooting the system. > Ad. 2. D3cold basically means the device has to go to D3hot plus all power > cut off from the device. While modern laptops typically support that with > modern standby (S0 idle) RTD3, bouncing through D3cold requires a > compatible mainboard design. Looking from the workstation's perspective it > would not be possible (unless one would do ACPI G3 cycle on each system > startup). Please correct me if I'm wrong. I am not at all familiar with these power management details. Is there some reason an ACPI G3 cycle would be bad? > Ad. 5. Some desktop Intel CPUs are GFX-less, which implies the usage of an > external GPU card. Would EFI OptionROM be allowed to run on display devices > in such case? Otherwise one may end up without the display working in the > firmware thus relying on booting in blind. If there is a non-spoofable way to distinguish the GPU card, and if the GPU card option ROM is not mutable, this would be okay. This could be ensured by e.g. having the hypervisor intercept and reject writes to it, together with ensuring that there are no other ways to write to it via the GPU. Another approach would be to require that the option ROM is digitally signed by the firmware vendor. Obviously, Thunderbolt device option ROMs must never be run, as removable devices must be considered untrusted. > Ad. 7. See Ad. 5. regarding Option ROMs. There is a way to go: extract the > EFI OptionROM, put it into the firmware image, and disable OptionROMs > entirely. However, it would require a custom firmware build for each > hardware setup/graphics card. Almost nobody would do it given that most > people do not have control over their firmware source code. What about something like LinuxBoot? Have the firmware load a basic Linux system, and have that kexec. This avoids the need for working graphics in the firmware, since the Linux kernel has its own drivers. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKghj0ACgkQsoi1X/+c IsE7Cg//VNwzsnFtVFZHDT4h2CnZ3uLHMqHqF0LWmFcQ77ofdcNwqMKpArICKC6B dI0C1+C6+jscJK5NQOp50ge9eCeZA1nVIfYSOkn+7RQ3KoXqHeeeOT7LlmEbfEI5 +pamNZ35SGu153Fw8OQsTH1J3nP5QC/e0vCTVbG1A8qy7+KhXL4G/OBFybgMlpCU PUSAImv7Y9uQhlqPg6Ll8okJR3ISjy7i2kPBjdC9AuQ7KgBrQkjU+OVCR75Rh87G 0HWF5/ns7ymmfhHEhFxHxvmhAMm89aRu4nRxYgnkoTRvTOsQrBorzk982m6iieou ga23xMxRZLDpke+z4KK+tuS8SqpHnYbAW/l+jkgkCT8Gts5+YWyzKP9evCuTQtTT eDf0cYSqRLl4RAoJYBKyrD2E7W8Cy54uUJ7O8Wy5CcwAqwcV4fD2AN8AAI+ah1HT S/fD6hhQNGs4qdYE8uatLws0E9dwffxwQp7cFI17LfuQajw8YEs3cnOjgWIKs405 stTmNFNKGAWL84aC7bycxcyD/tz3Y6jbLWLBEgW4KhDBd5k3hpb8sbrIJS/xHaQt t6HrN2N/d4hOdLYHTf7IoOEp17dvjONNZIIicHaWnEmNY2GzJ+2pMxk67z5Lp0fG ST4UCOopPq+7VV8m7rzNHVPqTQTEBxh2YyNp42o1arIfiZGvldI= =aDsF -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YqCGPqzQdbBpmsjL%40itl-email.
[qubes-devel] Future certification requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I would like to propose the following as future Qubes OS certification requirements. These would not apply for R4.1, but rather to a future (to be determined) release. Feedback would be appreciated, especially from hardware vendors. 1. Network and USB controllers (any device that would be attached to sys-net or sys-usb by default) must not have persistent mutable state. This also applies to internal USB devices attached to such a controller. Rationale: This ensures that the isolation provided by sys-net and sys-usb cannot be bypassed by inserting a backdoor into the attached PCI device. In particular, it means that if sys-usb (respectively sys-net) is a DisposableVM, a compromise of sys-usb (respectively sys-net) will not persist across reboots. 2. During any system startup, all DMA-capable devices must be bounced through D3Cold for long enough to ensure that all on-card non-persistent mutable state is reset. This must happen before PCI bus mastering is enabled. Devices that make no sense to pass through (such as i2c controllers) are excluded. Rationale: This is to ensure that any non-persistent mutable state is wiped before the device can perform a DMA attack. 3. The firmware’s network stack (if any) must be disabled by default. Rationale: This is a large attack surface that is almost never useful for desktops or laptops, except in corporate environments. 4. The firmware’s USB stack (if any) must not be enabled unless USB boot is selected. As an exception, if the machine has a separate USB controller for just HID devices, and the ports connected to this controller are clearly marked as “for trusted devices only”, the firmware may enable USB by default on this controller only. Rationale: This ensures that if someone has plugged a malicious USB device into sys-usb, and the system reboots unexpectedly, the device cannot exploit the firmware USB stack on the next boot. 5. Option ROMs for USB, network, and removable devices (including, but not limited to, Thunderbolt and ExpressCard) must be disabled by default. Rationale: This is to remove one means of performing early boot attacks if option ROMs turn out to be writable, even though they should not be writable. In the case of Thunderbolt and ExpressCard, executing option ROMs during boot allows for close-case attacks. 6. Removable devices must not be allowed to perform DMA until the operating system has explicitly permitted them to do so. Rationale: This prevents DMA attacks by removable devices, which are not trusted, even before the IOMMU is brought up. 7. Graphics cards must not have persistent mutable state, including option ROMs. Rationale: This is to prevent sys-gui-gpu ⇒ dom0 escalation, and to ensure that a graphics card that is attached to an untrusted qube (e.g. for gaming) cannot allow the untrusted qube to escalate its privileges. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKa2aUACgkQsoi1X/+c IsGMSxAAgbuyRu/8DrPDLt7KcLwgQB1O3JqJFBdeS4ZXMlhIeyBKwPdki3qJTuka 41q/TNRaCiNMPZcu1oRsTTfMuw8JfVuM51y+r2RdpDe6MikiQE1BKnNLI+sAmtwp pv/u5TyQIaCRlBfXoUjylEnk6gBuPlNECNC7hLjwS7VnMMoQnHkGLMlloEkKHKpP +AogAeLhRO0lQEWq1Tr/QRl8NnnAeAJ6Q/2d+m1mcu9OILkj2SsO8Q3nmvB6Rdw5 F18SgwB/jodhBcrbmVb5aI7MoD5vu4y/UyKZ5Wq1vPlrAY0NDrRhTasotvgt+7dX ioh7pWZ4W9JW7qCHhNrzft5aj/+ZJkYpiFpyz4iBQYARZwC4OnJUYiugRPiKxp09 gQXmhp1J9g1DgYR8mLzn1dT/BHFuHo5YS9ggFjg8oZaznU3wY+d8u4KD5m9k5VIW 2pzqCC63tyRQ1Z+GIptMsFtqcbVRuHBVK7Ld7FfcAMH/oHAgQymYJRcynir199zl u37sAdck1lqbQtMtD4bTbiloA3jenPReHoHywA6heJ0mrCjxdJmA+cxoDsaUjwvP KTB8QE7+BUERA0KzcyMDp/NI/DQTZ1n05+NKaCHb4qKY9ZUTSQmwEL8uOWv1Yda0 Z6LzdXZ9nITlf7w85R8HEP2bQ+8a1mZAb095jq0pCVDxDO3WdJU= =nIsN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YprZpVVHh65eK8IQ%40itl-email.
Re: [qubes-devel] TemplateVMs and secrets on private volumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 19, 2022 at 07:25:43AM +, Robert wrote: > On 5/19/22 01:18, Demi Marie Obenour wrote: > > *nix TemplateVMs and TemplateBasedVMs are in the rather unusual position > > of having a /etc that is effectively public, in that it is shared with > > untrusted code. > > > What is the recommended solution to this? Should /etc/ssh and > > /etc/pki/tls/private be part of the private volume by default > Why not have the user deploy security-sensitive data into the VMs using > bind-dirs? That is exactly what I was intending, but given that some directories in /etc should almost never be shared, I figured that they might belong in the default bind-dirs. The whole purpose of this is to reduce the likelihood of user error. Another option would be to use an overlayfs, as is done for the kernel module directory. This might be a better choice for /etc/ssh. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKGT6UACgkQsoi1X/+c IsF98g/+JwZ+IsIGQYiFY80jz3Tr//yuNEK4fRb26wl2vUFO1G1iYe7ShSZcxCsx 9ijoyqecJTQBL0Edrbs9I8s5VLiZrwF6Jk5IGh8SUD9+XJGCL8pPpN6DE/dYLaL4 f+nhEXxqQ8AttgVfX4WZv9g2sr8vPvUwNMBqQ3AOGwtYQ1SFX6jW8gjcIImxm//i /msknNjKQvHEvTIsSsjttiQzToc9Evhw/7KrHWYqbpyQ0mMapeqoEzGW5Ly8cWgI 2ZwadXqxs7INMxQgO9fmWnJRIkgPVRLL21XCNT51zTIegkfzPhL95TOjyh/fwTGj x+7lI9CXU6NyAMtVih3okOdhWWfVPyTA6NFY2gINeTzYW1jZVlfQCjoCq4S8zKKr hNhFVxbj9H1DATyCR7kh+emVM4QihCklTJojvCFmmziBXBXaBJpQpOe/aG3nGxKD sC1sYNwai7ieJV/EGTSpGiAmIDclyz/h4S0gh+BfQYtBLb3RBg8EnP6z/RLSH6oz uROKAKalLE4vXjvOvJl53B44RSLbp61CflNuqS4ikne9aoZtKRGqlX/dRKo6G5p1 QlfIP1+ohWb62NNkjDwnNDFyjgCT81ci6xXco9wHXD/op1govz3y0c12fO0YJo7G bSUA6sIzUs0sNPs4zhT19Jd19Qa/KAVlmIyUh/xyEqNhhnWdxfs= =2UIK -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YoZPpC0fm6jhgz5C%40itl-email.
[qubes-devel] TemplateVMs and secrets on private volumes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 *nix TemplateVMs and TemplateBasedVMs are in the rather unusual position of having a /etc that is effectively public, in that it is shared with untrusted code. Similarly, Windows TemplateVMs and TemplateBasedVMs have effectively a publically readable C: drive. This turns out to have some rather awkward consequenses. For instance, by default, a TemplateVM and all VMs based on it will share the same SSH host keys, even though the private parts of them are obviously supposed to be kept secret. Similarly, VMs based on a Windows template will have the same password hashes as the Windows template. What is the recommended solution to this? Should /etc/ssh and /etc/pki/tls/private be part of the private volume by default, just like /home and /usr/local are? Should the documentation for Windows qubes note that joining a Windows qube other than a StandaloneVM to an active directory domain is a bad idea? - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmKFfuMACgkQsoi1X/+c IsHakA/9FJMgrSuWzrIZHWaGXA5clsoBPdhATBNi4dOWt3nLw/cn7HfGNspgykti k4m8HjhnChKdd2puO4D74/KH1hTkf6CQqfGk8OP2UNO87Sm8nIWSt5zvGTbJe2JZ Wn2DsZsHbB0laL/Mz6yvhqCUazHLev1FzW+gm35H5td7HONeiQIEqZrZSzV1z4kX 0aAZUVqNCokv2lMUj6N1W7Sxe3mHSbmPL6OxPW0zYJ/Gz4IZVGOBjobGqsz3yVMj TP2sAk3gxAfTRvBaACnnGzSoVUE71oe4n+fQnBIr8hMOU2gnMn3Q+/UefL7g38sX BE/81UIq5o3YKq5sKTLpEswnMu6Vq3vm2+gLsu++55drDXziku9dudPsCo+vrsKD ir0RmXgQA7r4iuzl2lgfiWW9WhR4fHueBOPrba+OrHrK+6Hdyq3Ff8ZO0JS8yPga gzKN0eCFsEQjXxovnZ1f1oF8sm7qMaUC9okuvE2vY62MjpGry0fTz+fS8ujPLtpa xLf6v2PdGldXjmtl6PmZWeh9ec4ZEDIPD4PNLqN87FHBrd7bOWfW6vk/Nk7RBwWK cmrDzyv4emnGEHSjhGdkiPimXJiBMjceXMuzmNiK/KCufVDZOiHM8WHq+Y1E+4gw K/DE6kxP/NV/UMeU8C41+hhimGOvn7peydpiZiqo14o9BXJrArw= =/3pQ -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YoV%2B42dkT4hGKpVj%40itl-email.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Apr 20, 2022 at 03:46:35PM +, Rusty Bird wrote: > Marek Marczykowski-Górecki: > > On Wed, Apr 20, 2022 at 12:32:56PM +, Rusty Bird wrote: > > > Did you ever hear back from them? > > > > Yes, a month later, and it's not very optimistic one: > > > I'm unable to provide any further information about this for privacy and > > security reasons [...] > > Classic > > > Technically, the historical aspect of it isn't huge issue for us, as we > > try to not trust github too much (which includes having enough context > > in commit messages, having backups of issues, having notification email > > history etc). And honestly, I find searching through email notifications > > way more reliable than github's built in search. > > Email notifications include the comment ID: > > | Message-ID: > | [...] > | Reply to this email directly or view it on GitHub: > | https://github.com/QubesOS/qubes-issues/issues/7359#issuecomment-1086681239 > > Maybe GitHub's GraphQL could be queried to list all comment IDs etc. > for comparison - and to monitor if things are getting worse. That is a good idea. > > PS I have used gitlab.com recently in another project, for about 2 > > years. The project was _much_ smaller, in terms of number of issues, > > repositories count, contributions count, length of discussions and > > pretty much any other metric. And the subjective feeling was: gitlab is > > incredibly slower than github and much less stable. > > Also: gitlab.com often blocks me (or probably Tor users in general) > from even seeing CI results unless I log in, boo I suggest submitting a ticket about this. I would not be surprised if it is to prevent DDoS attacks. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmJgmIsACgkQsoi1X/+c IsEo6hAAixpd+oj+LB0chfyj67qjfnxlf6rsWVpPEqiIOVzPtmfW9xZrs/ILXZAJ dx0xxcY59dfZDPYd3mAU0drX7OGF+VyW7gKlGto6lnQWS0jBMoGNw1Hydxjsdz1n v8gOuPJxrhdvl1t69xgBD/YA0kIA66sH0niRtVWQ7XL8Mnd5IDXUg1hiqummLy42 k48FBD2icNnaqGKAcxgSz3RPXXmIWQryQQjFj6Zgw2N2dRXih1pmp3dHJnHef+oP 9jAkQGGC9sB0ng+oLuCFzn13frxl3/xMLLN2GESI8xky7KwuJCG0MJsfx1YfYiQl InUrn5RecNocRZDq0VEa6MeabDqYEXgqXMRd0FGBWKZYX5wQ1ACT2WiFm0d2XeXY I++qB40a8KSI75uJIPQv9DVAcHCyRYbVVfrnZdK10wskc3DzflZLsWUBu+IU3HnL 9lb9aTVBX/0iAXUQzkzibxiI580E4sGK8dUIN9+Tne7y8aHiHs6TbLCz8fQupE44 hIHJcsMhMRcY7iIPCtoppbJg49T+tZ1va8KzEQ3gJkaMe2hH4/F87WhGZFu8Wlnm UTapu+k/yVf+aww33JHT8Mm74OF62w8Rtlvsw4YcImotX6tFb9SJnobnHVhTWEJc 3CkCh2iNEEerShK48LOPY03rermE15MaWu0qkpguZYGF/wu4XME= =mliS -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YmCYi8PKx3OA0xoe%40itl-email.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
e would be something like, “Would it be possible to show comments not made by the account that opened the issue?”. > > I just read something disturbing that might be relevant: > > > > | Apparently, “suspending an account” on GitHub actually means *deleting > > | all activity for a user* — which results in (1) every pull request > > | from the suspended account being *deleted*, (2) every issue opened by > > | the suspended account being *deleted*, (3) every comment or discussion > > | from the suspended account being *deleted*. In effect, the user’s > > | entire activity and history is evaporated. > > > > | All of a sudden, I was seeing pull requests, issues, and comments > > | disappear from users who were actively contributing to the project. > > | *We lost valuable contributions, information, context, and discussion > > | history* on issues and pull requests. We even lost pull requests that > > | were open and under active review. That work is now entirely lost. > > | Gone forever. For pull requests that _did_ merge, we have the raw > > | commit history — but that is not a substitute for a full code review > > | and discussion. > > > > https://www.jessesquires.com/blog/2022/04/19/github-suspending-russian-accounts/ > > Indeed, we've seen this happening. But also, we've seen comments > associated to ghost user when original author's account is no longer > accessible. I'm not sure how the method of suspending an account is > chosen. > > Technically, the historical aspect of it isn't huge issue for us, as we > try to not trust github too much (which includes having enough context > in commit messages, having backups of issues, having notification email > history etc). And honestly, I find searching through email notifications > way more reliable than github's built in search. But that's still > inconvenience, especially for current ongoing work. Indeed it is, and a good reason to consider a different platform, such as GitLab or other self-hosted services. > PS I have used gitlab.com recently in another project, for about 2 > years. The project was _much_ smaller, in terms of number of issues, > repositories count, contributions count, length of discussions and > pretty much any other metric. And the subjective feeling was: gitlab is > incredibly slower than github and much less stable. There weren't a week > without "oh no, I need to type this long comment again, because > something went wrong and it wasn't saved", or "something didn't load, > try refresh few times until all the content loads". Since I (try to) not > trust web services for keeping code reviews, I have them always written > in a file first, so when this happens for a review comment, I just need > to paste it again. But that's still inconvenient. > So, while gitlab.com is an alternative, using it will cost us a lot of > frustration... I guess self-hosted instance won't be much better, but it > will require noticeable effort to maintain it (gitlab server > specifically has quite complex environment with several services > involved). Frédéric Pierret is already maintaining a GitLab instance, so I don’t think it would be too difficult for us to host one. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmJglp8ACgkQsoi1X/+c IsHzyBAAknQGSfc7M2NgoAvFvRry2m+qkxVxG9Kyp41wPNzKVwJrUjMSl2xwwv25 vqK92r3pNtr9DexsLsfKmKug7moSKgoj2HruuDv9RCaV+xdd+fhHj+ZP40pMYr9T CNQ3YU3aYbTiYxoo42K2DRgVAbMud3pY/U/g0VUQkhzCgd0/CetewunSjdGbPgV5 07KRcyZQCDWR/4Y9RTKx9RKO3G/oaVBHIXijwv6GFBroGP9ukvpPVCBp27/kixeg H9yvebYZXbpKLFrlrczKLKH0JYK8UK/UoJlOG2B9He+8H61EOI11XOWTySX6+/BS Qcuatz1pA4hw/5QOJTjYq8A9rOiYs1lTZy47Q5Jgw6frK/iT6EEBvDdn8BDdVA35 V7dE54DWwakGePNwPnvvRd9I8FnXbPMcD1JkekuME6qFvQBWnIrC9KWOfynkU/rE QFGFqhzTdk1NrXGcR+/A99gJQfMYCxPgaUHzsUsErjLVOrMP+hmBU3z6wW4vg8o8 0/9QzaMQVTn+p3l0X3R3kQPF/is2RE1SG5/ZbNJf6d/432WwYTWgve+oGBZ0z3s/ XzX7duoewO7e5Mi0cGuXse7Bh11RXt6lrEj1FKXooDowt0Ap6X3PStvTNQaxFK3C Q1hOSwhZQrsFjC0MlnAbQ1v8cPncbHniumGcIS/8BXjv1kf9V2k= =yx5i -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YmCWnuHFD50AjC9N%40itl-email.
[qubes-devel] Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 15:58, Adam Jackson wrote: > On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton wrote: > >> While this will eventually reduce workload for boot/installation >> components (grub2 reduces surface area, syslinux goes away entirely, >> anaconda reduces surface area), the reduction in support burden >> extends much further into the stack - for instance, VESA support can >> be removed from the distro. > > I'm flattered, but I intend to drop vesa in F37 regardless of the > outcome of this particular change. The only supported way to get to > graphics with vesa is to use Xorg, and we sincerely want to be out of > the business of maintaining Xorg the hardware server. (We'll need an X > server forever, Xwayland isn't going away, don't misread me here.) Does that mean that F37 will only have an Xwayland package, not an Xorg package? And does it mean that XFCE support is being deprecated? Qubes OS relies on the latter. > And frankly at this point if you seriously want to use vesa it's > because you're trying to like reverse engineer some obscure card's > VBIOS, and if you're doing that you're probably building your own X > server anyway, I know I would be. Its use as an emergency driver on > physical GPUs is negligible, we have native drivers for virtually > everything made in the last 20 years. Its use as an emergency driver > in virtual machines is more statistically significant, maybe, but even > there we usually have a drm driver these days, and where we don't we > can probably club it into bochs_drm since that's the only rom anyone > bothers to use for that. Do we have DRM drivers for the UEFI framebuffer and the standard QEMU-emulated graphics? -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YkzHdNKOjvlGWHoh%40itl-email. signature.asc Description: PGP signature
[qubes-devel] Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
On 4/5/22 15:58, Adam Jackson wrote: > On Tue, Apr 5, 2022 at 11:18 AM Ben Cotton wrote: > >> While this will eventually reduce workload for boot/installation >> components (grub2 reduces surface area, syslinux goes away entirely, >> anaconda reduces surface area), the reduction in support burden >> extends much further into the stack - for instance, VESA support can >> be removed from the distro. > > I'm flattered, but I intend to drop vesa in F37 regardless of the > outcome of this particular change. The only supported way to get to > graphics with vesa is to use Xorg, and we sincerely want to be out of > the business of maintaining Xorg the hardware server. (We'll need an X > server forever, Xwayland isn't going away, don't misread me here.) Does that mean that F37 will only have an Xwayland package, not an Xorg package? And does it mean that XFCE support is being deprecated? Qubes OS relies on the latter. > And frankly at this point if you seriously want to use vesa it's > because you're trying to like reverse engineer some obscure card's > VBIOS, and if you're doing that you're probably building your own X > server anyway, I know I would be. Its use as an emergency driver on > physical GPUs is negligible, we have native drivers for virtually > everything made in the last 20 years. Its use as an emergency driver > in virtual machines is more statistically significant, maybe, but even > there we usually have a drm driver these days, and where we don't we > can probably club it into bochs_drm since that's the only rom anyone > bothers to use for that. Do we have DRM drivers for the UEFI framebuffer and the standard QEMU-emulated graphics? -- Sincerely, Demi Marie Obenour (she/her/hers) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/9a3769b4-5d9d-920f-fa1f-4007f5002e33%40gmail.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key
[qubes-devel] Re: Orphaned packages (incl. go-rpm-macros) looking for new maintainers
Frédéric, would you be interested in taking python-magic-wormhole? I believe Qubes OS requires it for remote assistant. -- Sincerely, Demi Marie Obenour (she/her/hers) -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0ba98a9f-cf55-0226-29f2-df94d0b53d2e%40gmail.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Why code review is hard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Feb 12, 2022 at 05:31:04PM +0100, HW42 wrote:
> Brendan Hoar:
> > On Sat, Feb 12, 2022 at 7:03 AM David Hobach wrote:
> >
> >> Dear all,
> >>
> >> just stumbled across it and was wondering what a reviewer would
> >> expect from this code to do:
> >>
> >> ```
> >> #!/bin/bash
> >>
> >> function badCode {
> >> echo "bad code executed"
> >> }
> >>
> >> function testCode {
> >> #pick some existing file, nonexisting works too though
> >> echo "/etc/passwd"
> >> }
> >>
> >> function tfunc {
> >>local foo=
> >>foo="$(testCode)" || {echo "foo";}
> >>cat "$foo" || {
> >> badCode
> >> case $? in
> >> *)
> >> exit 1
> >> esac
> >> }
> >> }
> >>
> >> echo "Finished."
> >> ```
> >>
> >> At least on my amchine it executes "badCode" in both domU and dom0. I
> >> guess it's a bash bug and reported it accordingly, but anyway...
> >
> >
> > I’m not exactly sure what’s going on (and can’t bash right now) but
> > output grouping requires white space around { and } so that’s at least
> > one problem on the foo= assignment line. Maybe it’s being interpreted
> > as closing the function definition early?
>
> Yes you are on the right track here, I think. One problem is the missing
> space after the opening {
>
> $ false || {echo "foo";
> bash: {echo: command not found
> $ false || {echo "foo";}
> bash: syntax error near unexpected token `}'
> $
>
> So the } after the "foo"; closes the function. But why don't we get an
> error for the later } that don't match? Because bash operates line by
> line (remember those self extracting archives, that are shell scripts
> followed by a tar). If you change the *) into, say, x) (or anything that
> doesn't match $?) you see it:
>
> $ ./t2
> cat: '': No such file or directory
> bad code executed
> ./t2: line 22: syntax error near unexpected token `}'
> ./t2: line 22: `}'
> $
>
> So this is probably not even a bug. Thanks for the nice example David
> (apropos shell: set -e semantics are also "fun").
>
> Simon
I consider this a good reason to not use shell scripts for anything
non-trivial. There are some scripts in the builder which definitely
violate this rule. Also, `bash -n` will catch this.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmIIIgoACgkQsoi1X/+c
IsGQbQ//VtA3XGI5Cqcpa9sBSsChICtoHKq7m/qz2Fu3D/CDyAs0sNVrtq+ujLD8
1Mk/di/nfUzv7aBM6DBJoaaXMsmNpgQcx41aDM/AA7W+2MGKSPwVlcYYbxO7VsST
nQWEv3me4JRevvWNrQQUcPdkzV/alFSehKWfR05oHEAb7QMSIpwQs19YEprfRWV4
i6Dv1PTVSARTYry42Do9NT7lUi7YF786JpqV9H3/vkJOhf4IWm7Hb8CBasYykF1A
h6B2gx66PoiwK+qnJJesxoM8ePGhpvCjCw272FNy2TGuxeDa/zUYzWgkCgQNeUI/
dyEqmbDT410n4wDZtsHVvQLvoNYPGYjCMH0KoX95QJt/12ufzewPqaOTh2GvHr0w
hcIETVL02D5fgC0Rgt23SpB0aGJVQ13NM9nTi7Vy3kyhYv2N8/j5pQQpYszlLC2I
QOLmFDbPnaCvRU8BrhA4oQ6jaAZJNrKUtysOuQz3RJnXKV5kwNla9ys7b2ykCdJ5
oFWhxYgwk0HKuaFwpAbyJ+pXsb2Nq8rHYZrnzH4JKDUYX95SCCHcv4tSs+zcUpnW
D1a+PvR6NUSQUbncbt0eJq9UCyCioA2KlwZzfVf7iLdmdJvICB/kIszeDwt4BBQO
Lpjx1vFj4f+Db4zHi3ATOx9JazVxS6Lm7sCKgSnJcxUtzx9DGUI=
=iCAe
-END PGP SIGNATURE-
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/YggiCuECbgco8%2BGl%40itl-email.
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 11, 2021 at 05:48:10PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Oct 11, 2021 at 10:35:11AM -0400, Demi Marie Obenour wrote: > > On Mon, Oct 11, 2021 at 04:28:01PM +0200, Marek Marczykowski-Górecki wrote: > > > On Mon, Oct 11, 2021 at 09:13:18AM -0400, Demi Marie Obenour wrote: > > > > On Fri, Oct 08, 2021 at 02:21:58AM +0200, Marek Marczykowski-Górecki > > > > wrote: > > > > > On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > > > > > > Hi Marek and list, > > > > > > > > > > > > a qrexec service started by qrexec-agent (directly or via > > > > > > qrexec-fork-server) can request that instead of using stdin and > > > > > > stdout > > > > > > both side switch to using stdin bi-directional. To do so it needs to > > > > > > send SIGUSR1 to QREXEC_AGENT_PID. > > > > > > > > > > > > According to the git history [1] this has been added for usbip. As > > > > > > hinted in the commit message and in the comment [2] in the code this > > > > > > mechanism has a problem. To send a signal you need to be root or > > > > > > run as > > > > > > the same user as the receiving process. > > > > > > > > > > > > This lead to a corner case in the Python port of split-gpg2 [3] that > > > > > > tried to always switch to the bi-directional mode. During normal > > > > > > operation things worked since it's spawned through > > > > > > qrexec-fork-server > > > > > > that is running as user. But if the VM wasn't running the qrexec > > > > > > service > > > > > > in the freshly booted VM is spawned directly by qrexec-agent that > > > > > > runs > > > > > > as root and therefore sending SIGUSR1 failed. > > > > > > > > > > I think fixing that "TODO" shouldn't be that hard. The data handling > > > > > process (the one pointed with QREXEC_AGENT_PID) is already a separate > > > > > process, and I don't think it needs to keep root privileges. > > > > > This should be rather simple change, am I missing anything? > > > > > > > > I don’t think this is a good idea for two reasons. First, using SIGUSR1 > > > > is inherently not very reliable, as it is asynchronous and doesn’t > > > > provide any confirmation of signal receipt. > > > > > > I don't think it was ever an issue, but theoretically you are correct. > > > > Has this ever had any users other than USB pass-through? If not, it > > might explain some of the random failures there. > > Can you point at some specific bug reports? I'm only aware of two types > of USB passthrough issues: > - resetting USB device disconnects it (especially an issue for >connecting Android phones, which looks like a device reset on mode >switch) That explains why pass-through of an Android phone never worked! > - unsupported data transfer mode (should be better now, since the >current USBIP driver has XHCI support) I am glad to know that that issue is fixed. > > > > A better approach would be > > > > to pass an AF_UNIX stream socket as file descriptor 3, > > > > > > Then, the qrexec doesn't know where to send the data... > > > > I meant to use file descriptor 3 for out-of-band control messages. On > > further thought, I would actually prefer a *datagram* socket, > > I see, but TBH I don't like it that much. This makes writing a service > significantly harder, because (in some cases) it is no longer enough to > use standard read/write (or kill) which you can do trivially in any > language/tool etc, sending/receiving datagram over AF_UNIX is rather > uncommon thing (and often even sending UDP packets requires much less > common API). Good point. It is fairly easy in C, but doing it in most other languages requires calling the C functions. That said, another (even simpler) approach would be to treat data read from FD 0 as if it were read from FD 1, which doesn’t even require sending a signal. > On the other hand, I think one can rather easily get confirmation when > the parent qrexec processes the SIGUSR1 - simply by waiting for EOF on FD 1. I didn’t actually realize this. Since signals can’t actually be *lost* (merely coalesced), and since only one signal is actually sent, signals are actually reliable here. And I was not aware that qrexec would
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 11, 2021 at 04:28:01PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Oct 11, 2021 at 09:13:18AM -0400, Demi Marie Obenour wrote: > > On Fri, Oct 08, 2021 at 02:21:58AM +0200, Marek Marczykowski-Górecki wrote: > > > On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > > > > Hi Marek and list, > > > > > > > > a qrexec service started by qrexec-agent (directly or via > > > > qrexec-fork-server) can request that instead of using stdin and stdout > > > > both side switch to using stdin bi-directional. To do so it needs to > > > > send SIGUSR1 to QREXEC_AGENT_PID. > > > > > > > > According to the git history [1] this has been added for usbip. As > > > > hinted in the commit message and in the comment [2] in the code this > > > > mechanism has a problem. To send a signal you need to be root or run as > > > > the same user as the receiving process. > > > > > > > > This lead to a corner case in the Python port of split-gpg2 [3] that > > > > tried to always switch to the bi-directional mode. During normal > > > > operation things worked since it's spawned through qrexec-fork-server > > > > that is running as user. But if the VM wasn't running the qrexec service > > > > in the freshly booted VM is spawned directly by qrexec-agent that runs > > > > as root and therefore sending SIGUSR1 failed. > > > > > > I think fixing that "TODO" shouldn't be that hard. The data handling > > > process (the one pointed with QREXEC_AGENT_PID) is already a separate > > > process, and I don't think it needs to keep root privileges. > > > This should be rather simple change, am I missing anything? > > > > I don’t think this is a good idea for two reasons. First, using SIGUSR1 > > is inherently not very reliable, as it is asynchronous and doesn’t > > provide any confirmation of signal receipt. > > I don't think it was ever an issue, but theoretically you are correct. Has this ever had any users other than USB pass-through? If not, it might explain some of the random failures there. > > A better approach would be > > to pass an AF_UNIX stream socket as file descriptor 3, > > Then, the qrexec doesn't know where to send the data... I meant to use file descriptor 3 for out-of-band control messages. On further thought, I would actually prefer a *datagram* socket, with checks that the message actually came from the correct child process. > > or else just > > unconditionally accept data on either file descriptor 0 or 1. > > Almost, closing FD 1 must not be sent as EOF (after which, sending more > data over FD 0 wouldn't be possible anymore). And BTW, a heuristic of > "don't send EOF on FD 1 close, if any data was received over FD 0 > already" won't work, as for the usbip connection, the actual data is > exchanged only after FD is passed on to the kernel (after closing other > FDs). That is true. > > Second, > > this would allow the child process to ptrace() the parent process and > > obtain access to Xen file descriptors, which could potentially be used > > to escalate privilege within the qube. While this isn’t an explicit > > security boundary in Qubes OS, my understanding is that Qubes OS doesn’t > > try to deliberately weaken it either. > > Well, user processes must have the ability to open vchan connections > anyway, either for qrexec-client-vm to work, or for qrexec-fork-server. My understanding is that this typically requires membership in the “qubes” group, which is the same group that ‘qubes-core-agent-passwordless-root’ gives passwordless sudo access to. > > > > For split-gpg2 I switched, at least for now, to always use stdin/-out > > > > (maintaining two code paths would be ugly). > > > > > > > > Do we have plans to improve this? > > > > > > > > Beside the uspip case, are there any advantages of having a > > > > bi-directional stdin? > > > > > > Yes, I'd consider making split-gpg2 a socket-based service (with one > > > process handling several requests, to avoid process startup delay). For > > > this, it needs to transfer data over a single socket FD. > > > > I fully support this, but with two significant caveats. The first is > > that one must ensure the socket is present and listening before qrexec > > tries to connect to it. This isn’t trivial for a service not running as > > root. > > We could have a system unit with User= setting. Good point. >
[qubes-devel] Re: Switching to bi-directional stdin when qrexec-agent and child run as different users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Oct 08, 2021 at 02:21:58AM +0200, Marek Marczykowski-Górecki wrote: > On Fri, Oct 08, 2021 at 02:12:08AM +0200, Simon Gaiser wrote: > > Hi Marek and list, > > > > a qrexec service started by qrexec-agent (directly or via > > qrexec-fork-server) can request that instead of using stdin and stdout > > both side switch to using stdin bi-directional. To do so it needs to > > send SIGUSR1 to QREXEC_AGENT_PID. > > > > According to the git history [1] this has been added for usbip. As > > hinted in the commit message and in the comment [2] in the code this > > mechanism has a problem. To send a signal you need to be root or run as > > the same user as the receiving process. > > > > This lead to a corner case in the Python port of split-gpg2 [3] that > > tried to always switch to the bi-directional mode. During normal > > operation things worked since it's spawned through qrexec-fork-server > > that is running as user. But if the VM wasn't running the qrexec service > > in the freshly booted VM is spawned directly by qrexec-agent that runs > > as root and therefore sending SIGUSR1 failed. > > I think fixing that "TODO" shouldn't be that hard. The data handling > process (the one pointed with QREXEC_AGENT_PID) is already a separate > process, and I don't think it needs to keep root privileges. > This should be rather simple change, am I missing anything? I don’t think this is a good idea for two reasons. First, using SIGUSR1 is inherently not very reliable, as it is asynchronous and doesn’t provide any confirmation of signal receipt. A better approach would be to pass an AF_UNIX stream socket as file descriptor 3, or else just unconditionally accept data on either file descriptor 0 or 1. Second, this would allow the child process to ptrace() the parent process and obtain access to Xen file descriptors, which could potentially be used to escalate privilege within the qube. While this isn’t an explicit security boundary in Qubes OS, my understanding is that Qubes OS doesn’t try to deliberately weaken it either. > > For split-gpg2 I switched, at least for now, to always use stdin/-out > > (maintaining two code paths would be ugly). > > > > Do we have plans to improve this? > > > > Beside the uspip case, are there any advantages of having a > > bi-directional stdin? > > Yes, I'd consider making split-gpg2 a socket-based service (with one > process handling several requests, to avoid process startup delay). For > this, it needs to transfer data over a single socket FD. I fully support this, but with two significant caveats. The first is that one must ensure the socket is present and listening before qrexec tries to connect to it. This isn’t trivial for a service not running as root. The second is that right now, one can use user= directives in qrexec policy to control which qube has access to which keys. While this is not best practice, on memory-constrained hardware it can be the difference between being able to use split-gpg and not being able to do so. - -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmFkOG4ACgkQsoi1X/+c IsET/g//TSCwHp1MFIJvSSMc/KqqOWcMc8DAFI0qW08SlNTeXb2Cpc/p9iNbrhih 9zDZEDGG8s188hQwzn3hACJot1ibBxGQr6T6zqx/zm7iWZKYU/8eSDzW61HCtnuf CUpPCHqPeMxjDpgfKzo7JpooZ4HB1oVkkXjpaiJMCShnXGHYHXf22vV/Xh0yaapi XDPTtKACHqqBgrlogzM8mbt8FX/KraCMY2cvheZA/l+gGbIIamvr/VxSnnOFfN8O o3rSYJOICDgSCrl2DWnpupB07TZYg8mmsUwnOYWNCJay7zAmC6eixFPbFYrmrFNW Pm5w/HZLteS6sS1mwq1Ap8p1zlXSkTqPLay2Qt+S3ip6h7hE0JnXwbqN7C4jAMlp THA+aqmJZQsusZ7TM7H9LeFViIJRRKjWJ98JEu5n6zE65dmnJC5xgHR0PkCpHY8q oYB4CM628DWffOsvseXwQapbjk5JSAjr/z9zHK/8B6n7EWYzrw1UPMjF0bs0WHdg dHdB8NT42hs+ZP2xOuGgylLtsYxuTqnhnVp2VLLGgl5edUdmd9312JkwcwPfskTy HvsC4+4V/3mLvnlkDTvH36hzeGoSqkPtAUrW4v5+ZEmDjfYDOFxNMjDTys4jGoxE dBNWMhUBEdgsShWsJ+rZVtU9h+TFKKSj08uakeHQPLCVwVwfS7k= =5Xrk -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/YWQ4brAbFidMwYBn%40itl-email.
Re: [qubes-devel] Re: QSB-069: Multiple Xen and Intel issues
On 6/9/21 6:52 PM, Andrew David Wong wrote: > On 6/9/21 12:08 AM, Vít Šesták wrote: >> Is it OK to see ”cat: broken pipe“ during update of the microcode package? >> It still boots. Note that the machine has an AMD CPU. >> > > Not sure. I experienced the same thing. See scriptlet output line 1 below: > > ``` > [...] > Transaction performed with: > Installed dnf-1.1.10-6.fc25.noarch @anaconda/rawhide > Installed rpm-4.14.2.1-5.fc25.x86_64 @qubes-dom0-cached > Packages Altered: > Upgraded microcode_ctl-2:2.1-32.qubes1.fc25.x86_64 @qubes-dom0-cached > Upgrade3:2.1-33.qubes1.fc25.x86_64 @qubes-dom0-cached > Upgraded python3-xen-2001:4.8.5-32.fc25.x86_64 @qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64 @qubes-dom0-cached > Upgraded xen-2001:4.8.5-32.fc25.x86_64 @qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64 @qubes-dom0-cached > Upgraded xen-hvm-2001:4.8.5-32.fc25.x86_64 @qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64 @qubes-dom0-cached > Upgraded xen-hypervisor-2001:4.8.5-32.fc25.x86_64 @qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64 @qubes-dom0-cached > Upgraded xen-libs-2001:4.8.5-32.fc25.x86_64@qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64@qubes-dom0-cached > Upgraded xen-licenses-2001:4.8.5-32.fc25.x86_64@qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64@qubes-dom0-cached > Upgraded xen-runtime-2001:4.8.5-32.fc25.x86_64 @qubes-dom0-cached > Upgrade 2001:4.8.5-34.fc25.x86_64 @qubes-dom0-cached > Scriptlet output: > 1 cat: write error: Broken pipe > 2 Generating grub configuration file ... > 3 Found theme: /boot/grub2/themes/system/theme.txt > 4 Found linux image: /boot/vmlinuz-5.4.107-1.fc25.qubes.x86_64 > 5 Found initrd image: /boot/initramfs-5.4.107-1.fc25.qubes.x86_64.img > 6 Found linux image: /boot/vmlinuz-5.4.98-1.fc25.qubes.x86_64 > 7 Found initrd image: /boot/initramfs-5.4.98-1.fc25.qubes.x86_64.img > 8 Found linux image: /boot/vmlinuz-5.4.88-1.qubes.x86_64 > 9 Found initrd image: /boot/initramfs-5.4.88-1.qubes.x86_64.img >10 Found linux image: /boot/vmlinuz-5.4.107-1.fc25.qubes.x86_64 >11 Found initrd image: /boot/initramfs-5.4.107-1.fc25.qubes.x86_64.img >12 Found linux image: /boot/vmlinuz-5.4.98-1.fc25.qubes.x86_64 >13 Found initrd image: /boot/initramfs-5.4.98-1.fc25.qubes.x86_64.img >14 Found linux image: /boot/vmlinuz-5.4.88-1.qubes.x86_64 >15 Found initrd image: /boot/initramfs-5.4.88-1.qubes.x86_64.img >16 Found linux image: /boot/vmlinuz-5.4.107-1.fc25.qubes.x86_64 >17 Found initrd image: /boot/initramfs-5.4.107-1.fc25.qubes.x86_64.img >18 Found linux image: /boot/vmlinuz-5.4.98-1.fc25.qubes.x86_64 >19 Found initrd image: /boot/initramfs-5.4.98-1.fc25.qubes.x86_64.img >20 Found linux image: /boot/vmlinuz-5.4.88-1.qubes.x86_64 >21 Found initrd image: /boot/initramfs-5.4.88-1.qubes.x86_64.img >22 done > [...] > > ``` This is normal, but it is still a bad user experience. The culprit is probably a shell script being invoked via systemd, but without IgnoreSIGPIPE=false set (default is true). Please file an issue. -- Demi Marie Obenour she/her/hers QubesOS Developer, Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/b20a62b4-72c3-285f-a913-cb5ea8259a5c%40invisiblethingslab.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[qubes-devel] Request for feedback: reflink storage pool & Linux storage stack development
QubesOS currently defaults to using LVM2 for storage, but it also supports using BTRFS and XFS via the reflink storage pool. How have people’s experiences with reflink been, and how have they compared to the default LVM2 pool? Additionally, reading the linux-lvm mailing list has made me question if the performance characteristics of LVM2 are a good fit for QubesOS. LVM2 seems to focus on high throughput at the expense of ease of recovery, checksumming, and the time needed to create a snapshot. In Qubes OS, however, the time needed to create a snapshot is absolutely critical, as three of them are needed for each qube start. There are obviously several options here: - Stick with LVM2 - Switch the default to BTRFS + reflink. - Switch the default to XFS + reflink on top of LVM2. - Use XFS + reflink on top of Stratis [1]. - Write our own pool on top of device-mapper. - Use ZFS; this cannot be the default, but it could be available as a contrib package. - Something else that I have not listed, or not considered. What are the advantages and disadvantages of each of them, and what would be the best default going forward? [1]: https://stratis-storage.github.io -- Demi Marie Obenour she/her/hers QubesOS Developer, Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/8fb6a9cb-259c-8b5a-543e-1adcd10e59ff%40invisiblethingslab.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Updates from CentOS/Fedora Land
e offers this guarantee. Combined with openSUSE Leap’s release cadence, this means that we can use a single, *supported* version of openSUSE for an entire QubesOS release if the release schedules line up. And if they do not, we will need to upgrade dom0 at most once. Furthermore, openSUSE users are first-class citizens in the ecosystem. SUSE backports fixes for packages in openSUSE Leap even if they are not part of SUSE Enterprise Linux. Feature requests by openSUSE users that have sufficient justification result in internal support tickets being filed. And not only does openSUSE sign its metadata, openSUSE’s package manager (Zypper) *requires* signed metadata by default. Only with user consent will it fall back to trusting package signatures. > While it will take time for this work to yield results, I was able to find > many of the packages from fepitre’s copr repo in EPEL and AppStreams and > the AltArch SIG apparently already carries a backported kernel. I think > it's worth exploring collaboration through the CentOS Special Interest > Groups [sigs] and/or a custom [Fedora]/[CentOS]/[Silverblue] distro to > expand the package availability and upstream maintenance. A backported kernel would very much help, but it isn’t enough. For obvious security reasons, we cannot use third-party repositories unless we have complete trust in their maintainers. The Silverblue approach of an immutable base image and atomic updates is a fantastic fit for our dom0, but those two items alone are not enough to compensate for the disadvantages. Overall, I strongly recommend that we move away from Fedora and towards openSUSE Leap as quickly as possible. While R4.1 is too far along to make such a change in dom0, offering an openSUSE template for it should be possible. And we can switch dom0 in R4.2. -- Demi Marie Obenour she/her/hers QubesOS Developer, Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ecf7e86f-0f83-a4ee-016b-913bf8cbf89d%40invisiblethingslab.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-devel] Cleanup on qubes file server (bruschetta)
On 3/19/21 10:20 PM, Marek Marczykowski-Górecki wrote: > Hi, > > I want to do a little cleanup on the server, to make more room for the > packages. Here is the disk usage of repo/yum/ dirs: > > 472Mr1 > 19G r2 > 18G r3.0 > 21G r3.1 > 59G r3.2 > 157Gr4.0 > 71G r4.1 > 342Gtotal > > Based on the stats[1] (which are built based on the updates server > hits), versions below 3.2 are basically unused. So, I'd like to remove > them from the server. In fact, since 3.2 is EOL for almost 2 years > already, I think this also could be removed (there won't be any new > updates there, ever). Does anyone see any reason to keep them online, on > the same server, under same URL? Note this content is also mirrored, so > removing it from here will also reduce storage usage on all the mirrors. > > [1] https://www.qubes-os.org/statistics/ I see no reason they need to be on the main server, and certainly not mirrored. That said, they should still be publicly available as they are of historical interest. -- Demi Marie Obenour she/her/hers QubesOS Developer, Invisible Things Lab -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4a16ccda-9c63-6a72-5dbe-b485c2b4fa75%40invisiblethingslab.com. OpenPGP_0xB288B55FFF9C22C1.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
