[qubes-devel] Re: Performance of software video decoding
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 06, 2024 at 11:59:30AM -0500, Demi Marie Obenour wrote: > On Sun, Nov 03, 2024 at 05:00:03PM +0100, Marek Marczykowski-Górecki wrote: > > Hi, > > > > I just did some testing on a laptop with 4K screen and i9-13900H CPU. > > The test case is Big Buck Bunny videos[1] in various formats, played > > with "parole" (default video player in the default xfce template) which > > uses gstreamer. > > > > Playing 4K version of the video fails completely, I get maybe 0.5fps or > > even worse. This applies to both 30fps and 60fps files. > > > > Playing FHD version in its original size works just fine both at 30fps > > and 60fps. > > > > Playing FHD version scaled up to the full screen works just fine at > > 30fps, but starts dropping frames at 60fps quite quickly (especially > > during more dynamic scenes). > > > > Just FYI, there is no any action needed. > > > > [1] http://bbb3d.renderfarming.net/download.html > > I got much better results with Google Chrome playing a 4K video from > YouTube. This led me to check on #gstreamer:gstreamer.org, and the > developers there found that the problem is with the OpenH264 decoder > that Fedora ships. Other H.264 implementations handle it just fine. Interesting, does it mean it works just fine on Debian for example? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmcrstwACgkQ24/THMrX 1yxmYgf7BDCo6fkCBbimAMLZW3Wu8idd5kbMlM1rxxK1SSFpXQwW9K+0nYmyfnjU USCwedO+CIdeorgnf8e6wxzFbh2j5x+9iHKjlERh+F3N3KOf08HZpQ0dHItW+KtY 5wPDtiuZ23IWUp5BG7B4xtnaq7F1GVOKxEOf4OYamFbVdyh944GuHm7wpEtr26dL bml2nfV2Kuwy0MxQph/Uk1hsO5/37bJluc+yFO73ngP5s2t63fe8v+tS7z8y1eRI dxoWEUeTfjTbPRQOWTie98eGUG4xjecs93QD9LJKWPing5jkK5MnzURvBmVqiJ8u 81KWf0ExbLUQdZps0AWPT0fwkn8hvQ== =trwv -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 visit https://groups.google.com/d/msgid/qubes-devel/Zyuy3Fa1dfsZ6zpJ%40mail-itl.
[qubes-devel] Performance of software video decoding
Hi, I just did some testing on a laptop with 4K screen and i9-13900H CPU. The test case is Big Buck Bunny videos[1] in various formats, played with "parole" (default video player in the default xfce template) which uses gstreamer. Playing 4K version of the video fails completely, I get maybe 0.5fps or even worse. This applies to both 30fps and 60fps files. Playing FHD version in its original size works just fine both at 30fps and 60fps. Playing FHD version scaled up to the full screen works just fine at 30fps, but starts dropping frames at 60fps quite quickly (especially during more dynamic scenes). Just FYI, there is no any action needed. [1] http://bbb3d.renderfarming.net/download.html -- Best Regards, Marek Marczykowski-Górecki 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 visit https://groups.google.com/d/msgid/qubes-devel/ZyeeA6JweWQlEVZm%40mail-itl. signature.asc Description: PGP signature
Re: [qubes-devel] Should Bind-dirs be app qube-editable? (minimal state app qubes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Sep 27, 2024 at 08:06:01PM +, deeplow wrote: > > > For Windows vs Linux I agree, but at least /home is the same under > > > almost every *nix I know of. > > > > > > > > Yet, there is no qubes-core-agent (nor qubesdb) in any of them, so it's > > irrelevant. In any case, there is "os" feature that can be used to > > distinguish OSes (that have qubes tools installed), and also we have > > proper mechanism for feature discovery - "supported-feature" namespace - > > for a template to announce support for this configurable bind-dirs. > > That's important, because it isn't enough to say "Qubes 4.3 supports > > this" - you may have template imported from 4.2 for example, or some > > custom build or whatever. We can use a similar mechanism to give some > > hits for the GUI about configuring this thing if needed (which I doubt > > will happen anytime soon - I don't see a practical chance for non-Linux > > support of this feature happening). > > True. > > I guess practical next steps are to file and issue with the conclusion > of this discussion either on #1006, #3258 and close the other one. > Is this the correct way to go about this? Or does it need anything else? Yes, #1006 looks like logical place to track this feature. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb3Jd0ACgkQ24/THMrX 1yztAAgAjUlcRSQuPg6Us0Z/NT4ifNML3ZR9waoNYjbd/UgjG0Q8TyQY+yAbNzcz MBf9el3JhIKn2hTbtDhOz7gjFArAc+JOyB3VsbJgBCAyynlVksT+4tE7Dw9JzvII +rxHIgEmMeUeeLyY6Q1P95RKGhE1ACLSIHNvddMTBxkVc6GOIEI18RofY4m+PSNT 1UQJ3G1NEjPXYd1qbxhSnTN5SjHgsQo49MLU8S1MhB2kbc0NiVRzid7GDfejjxZb dN2fhyK0gCPCNt9XQ7Y105Ef0IYo1Y1svu05T8ltPYo+j+NMx/+c76q75dVREij3 /dwHr+RS+fE8sftz/iTE9nS2PZgJbw== =mxKG -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/Zvcl3dT82ue49_2M%40mail-itl.
Re: [qubes-devel] Should Bind-dirs be app qube-editable? (minimal state app qubes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Sep 26, 2024 at 03:22:41PM +, deeplow wrote: > On Thursday, September 26th, 2024 at 3:55 PM, Marek Marczykowski-Górecki > wrote: > > I like this! > > Nice! > > > We could put that into vm-config, or even have a new place > > (bind-dirs prefix?). > > A dedicated prefix sounds even better! Perhaps even a chance to get > a less implementation-specific name like "persistent-app-dirs". > But either way is even better than (ab)using vm-config. One thing to consider is length limitation of qubesdb keys - 63 chars. Values can be much longer (3k). So, the longer the prefix, the shorter actual key. But it isn't necessarily a problem, the actual path can be put as a value, and key could be something short like "123-my-first-path" (in most cases ordering doesn't matter, but in the few cases where it does, better to have this numbered prefix). > > If present, configuration in /rw/config would be ignored and > > maybe also /home not bind-mounted anymore (unless > > listed in bind-dirs explicitly?). > > I think /home could be added by default to this bind-dirs prefix > when creating a new qubes otherwise getting started on Qubes would > even be more difficult. Installed programs in app qubes "mysteriously > disappearing" is a commonly reported issue in the forum. > > So my suggestion would be to keep the default experience, but allowing > advanced users to remove /home persistence if desired. This way we'd > keep regular users happy (because nothing broke) and advanced users with > yet another tool in their toolbox. Yes, this is kinda what propose: on the backend level, have implicit default include /home, but if you start configuring it manually, you'd need to include /home (if desirable) yourself too. Ofc, the (G)UI could propose this option for you to make it easier. > One aspect to also think about is how to do this "default home persist" > in a multi-OS way. Perhaps the default bind-dirs could be obtained > template's preferences. Maybe stored in "os-home-dirs"? I don't think any path in bind-dirs setting could be made OS-agnostic... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1gPIACgkQ24/THMrX 1yyPaQf/dO8D5v4iNV4HvLeeR82RBIeV0CycJLvQ8Qnc8Viy8eZASau6s4GSaDxC MVAMGBEUo5o6gengGxuTd4u3kT9OmgfCH9AXbv0p9vGkc6fGkcwYvUvWDNY8sjHG z6Jf6U+l6RJDt6xTq/wsbEGSo9Ctj41cA5ewb+FjZLcI4Gt2vIIISLt8YCOAVhp5 wQr3bPpxwcSNo/Qi+NPu8fPWeJJsyYDpesdYFnbeC42Qc1UZ1OtiblwF3GN30JCY sYql4BJD9yiEkbTbgfhBOHOkYElevo92y5xfWgXbLXantzwoo2MJaW8vuGanXbQi NgshVojXlh/UHYBSEhOCdH3rKoAbVw== =GwdK -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/ZvWA8lG5V-tCK9NF%40mail-itl.
Re: [qubes-devel] Should Bind-dirs be app qube-editable? (minimal state app qubes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Sep 26, 2024 at 12:30:07PM -0400, Demi Marie Obenour wrote: > On Thu, Sep 26, 2024 at 05:42:42PM +0200, Marek Marczykowski-Górecki wrote: > > On Thu, Sep 26, 2024 at 03:22:41PM +, deeplow wrote: > > > On Thursday, September 26th, 2024 at 3:55 PM, Marek Marczykowski-Górecki > > > wrote: > > > > I like this! > > > > > > Nice! > > > > > > > We could put that into vm-config, or even have a new place > > > > (bind-dirs prefix?). > > > > > > A dedicated prefix sounds even better! Perhaps even a chance to get > > > a less implementation-specific name like "persistent-app-dirs". > > > But either way is even better than (ab)using vm-config. > > > > One thing to consider is length limitation of qubesdb keys - 63 chars. > > Values can be much longer (3k). So, the longer the prefix, the shorter > > actual key. But it isn't necessarily a problem, the actual path can be > > put as a value, and key could be something short like > > "123-my-first-path" (in most cases ordering doesn't matter, but in the > > few cases where it does, better to have this numbered prefix). > > > > > > If present, configuration in /rw/config would be ignored and > > > > maybe also /home not bind-mounted anymore (unless > > > > listed in bind-dirs explicitly?). > > > > > > I think /home could be added by default to this bind-dirs prefix > > > when creating a new qubes otherwise getting started on Qubes would > > > even be more difficult. Installed programs in app qubes "mysteriously > > > disappearing" is a commonly reported issue in the forum. > > > > > > So my suggestion would be to keep the default experience, but allowing > > > advanced users to remove /home persistence if desired. This way we'd > > > keep regular users happy (because nothing broke) and advanced users with > > > yet another tool in their toolbox. > > > > Yes, this is kinda what propose: on the backend level, have implicit > > default include /home, but if you start configuring it manually, you'd > > need to include /home (if desirable) yourself too. Ofc, the (G)UI could > > propose this option for you to make it easier. > > > > > One aspect to also think about is how to do this "default home persist" > > > in a multi-OS way. Perhaps the default bind-dirs could be obtained > > > template's preferences. Maybe stored in "os-home-dirs"? > > > > I don't think any path in bind-dirs setting could be made OS-agnostic... > > For Windows vs Linux I agree, but at least /home is the same under > almost every *nix I know of. Yet, there is no qubes-core-agent (nor qubesdb) in any of them, so it's irrelevant. In any case, there is "os" feature that can be used to distinguish OSes (that have qubes tools installed), and also we have proper mechanism for feature discovery - "supported-feature" namespace - for a template to announce support for this configurable bind-dirs. That's important, because it isn't enough to say "Qubes 4.3 supports this" - you may have template imported from 4.2 for example, or some custom build or whatever. We can use a similar mechanism to give some hits for the GUI about configuring this thing if needed (which I doubt will happen anytime soon - I don't see a _practical_ chance for non-Linux support of this feature happening). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1j+oACgkQ24/THMrX 1yzKKgf9Em2yJ19Z74fB4OPAI+FG5+ZbsiKAK07dDa0FtHM9oPjWnG/Am/YP/KG1 7n/Z9nihN8/qpO+InOVvO+1uiff060rrTy0rdHmjzPMh5eXvXqaJQIfgGd/FOxX+ PLAA+a/LB9zNqS82LdIovIfDe8yZ515zdHje1mDuytCqNR3Zq9YWFRqgDUOOL3+o OUm74qAJ7sjPOLXdXjbYNSfcuh7wurTNqK4NVSkq1Tvl/ghlbZt3/KTikdmrwen5 j6hRFrhgYer40oAIMkd6pTcPwBlsmooNVs9uopkMv4Py7seE9JQlBM96EQoaZoJx k6daZDqDNh5P4DJQ49+MpcoWv1fCCw== =E0pT -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/ZvWP6t0_RYTUxTdW%40mail-itl.
Re: [qubes-devel] Should Bind-dirs be app qube-editable? (minimal state app qubes)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Sep 26, 2024 at 02:48:18PM +, 'deeplow' via qubes-devel wrote: > Hello, > > Disposable qubes are the gold-standard in mitigation malware persistence, but > in the context of an app qubes one only needs to store a malicious script in > /rw/config/rc.local to get persistence. > [#1006](https://github.com/QubesOS/qubes-issues/issues/1006#) and > [#3258](https://github.com/QubesOS/qubes-issues/issues/3258) add interesting > points about making only bind-dirs be all that persists in an app qube. > Getting persistence in a white-list style bind-dirs would require an attacker > to exploit applications which read persisted configuration files / > directories instead of just a simple bash script. > > Further hardening of certain applications would become possible. For example > > - storing network configurations in sys-net > - storing browser profiles > - etc. > > However, even if said mitigations were to be implemented, bind-dirs would > still editable within the app qube through /rw/config/qubes-bind-dirs.d > (highest priority, for per VM configuration), which [3hhh hints > at](https://github.com/QubesOS/qubes-issues/issues/3258#issuecomment-725516370). > This makes such eventual persistence mitigations irrelevant from within app > qubes. > > So my suggestion is: now that we have a way to expose configuration values to > to qubes (through > [vm-config](https://dev.qubes-os.org/projects/core-admin-client/en/latest/manpages/qvm-features.html#vm-config)), > to have bind-dirs stored as a vm-config, potentially replacing > /rw/config/qubes-bind-dirs.d. This way it would editable only from its > AdminVM (kind of like firewall rules). In particular for sys-net, this would > open up the possibility of having salt set said bind-dirs by default and have > only networks configurations persist. I like this! We could put that into vm-config, or even have a new place (bind-dirs prefix?). If present, configuration in /rw/config would be ignored, and maybe also /home not bind-mounted anymore (unless listed in bind-dirs explicitly?). One remaining question is interaction with template-stored configuration (/usr/lib/qubes-bind-dirs.d) - I guess it should be respected in that case, correct? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmb1dfEACgkQ24/THMrX 1yzfIwf9GIw3cKl4SOYkhjw0GyTy01viP0tYSJ39BOivq7gXnQii2SQ1cm49fDu+ Dh76xSqxYnTIUZ8w3ACNG8+gbdlT6GlLca5j1DNVFHGNApk6BPI6dVy83I/p3HV2 AJsE2m9N4dzHjtdShCZpjIJJU3855yCmn7cQyrYopXeignce5NfSzHsi/y+l4zYo sdkp5GCVEvJPfGhhv62y43s6458U2g2Pl8OKYqel4E9Zcw/waZOWn23ziw17yOm8 dqwGVmb1cxJ5Xr078Ke1faIk0koavrQaz7+rlGe7+RCsZ8Cal3cO3UT7aVmVSIa5 6O0FDvBcCQcTXooGEeAmz7rfYjAi0w== =qpTD -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/ZvV18X-ZsR48RKx-%40mail-itl.
Re: [qubes-devel] Increase NFTables rule matching speed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Jun 05, 2024 at 06:33:42PM +0200, Ben Grande wrote:
> Hello qubes-devel,
>
> Is it worth it looking into improving QubesOS NFTables rule matching
> speed? In order of speed: `if` > `ifgroup` > `ifname` (output and
> input). Qubes uses a mix of them. Should work regarding changing the
> rules to have a faster matching be worth it?
>
> Some rules matching 'iifname "vif*"' could be changed to 'iifgroup 2'.
>
> Rules of a netvm:
>
> $ sudo nft -s list ruleset | grep iif
>
> iifgroup 2 goto antispoof
> iifname . ip saddr @allowed accept
> iifgroup 2 udp dport 68 counter drop
> iifgroup 2 meta l4proto icmp accept
> iif "lo" accept
> iifgroup 2 counter reject with icmp host-prohibited
> iifname . ip6 saddr @allowed accept
> iifgroup 2 goto antispoof
> iifgroup 2 goto _icmpv6
> iif "lo" accept
> iifname != "vif*" accept
> iifname != "vif*" ip saddr { 10.137.0.67, 10.137.0.90, 10.138.35.169,
> 10.138.38.234 } drop
> iifname != "vif*" accept
> meta l4proto { tcp, udp } iifgroup 2 oifgroup 1 flow add @qubes-accel
Take a look at the "Firewall antispoofing in ingress hook" thread, it
goes even further for some parts.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZglAYACgkQ24/THMrX
1yzlSQf/aQc8SkF4Ijy3Jz300HNdMvQbmKufzh4qSokRKWbySRJgVOtDWhMNMDCG
h8QMExbgLJm8/sUIJvmhjACCyTsV76UGbpgA8RST7gxXTrK+7yJTZ8rCuUNhZXpU
+VFHRZun/agBMK/WiVW8IrksBz80oQ48XGU/IexQaLCS9meQrm+ydEn0E72hHA3u
osNxwKZoLjDkq7An+a74er/vgCdKFRp7rQWupsq7gPyI+eBa3CMMumMlSZSHSDhB
T1pd5ykzTIREZUO7GBQ+rZPjgSlBU1EaQm2UNlXKVSukBtQqzj6U8pp01ebFs/PH
p92Lj179p2jB3Z+XDEodhtsyiUekxw==
=SyDH
-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/ZmCUBma0HJIcMOgN%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 03, 2024 at 08:08:22AM -, qubist wrote: > On Sun, 2 Jun 2024 20:34:33 +0200 Marek Marczykowski-Górecki wrote: > > > sys-net is [...] the sandbox that may become compromised due to > > direct network access. > > Exactly why I ask: what value has a firewall in sys-net at all? If we > assume it can be compromised at any time, how are we protecting > anything through antispoofing its uplink interfaces? Not much. But the same firewall applies to sys-firewall, VPN qubes and some other configurations. And in those cases it matters a bit more. > > It's the role of sys-firewall (among other things) to protect > > other qubes from outside network, including potentially compromised > > sys-net. That's why anti-spoofing rules are important on eth0 too. > > But you also say: > > On Thu, 23 May 2024 15:53:39 +0200 Marek Marczykowski-Górecki wrote: > > > Well, this is too broad, as for example sys-net is allowed to use its > > own IP to send packets down the network (like to sys-firewall or other > > qubes). > > Do you mean (conntrack) established,related? It may cover some of those cases, yes. But I'm not sure if all (check for example if traceroute would still work). But also, that sentence was about the long list of subnets that shouldn't appear on the internet, but in most cases you connect to LAN first, and those would be filtered out too. Generally, if you have a link to some network (or even a single host), it is wrong to filter out its source IP as spoofed one, because it isn't spoofed. > > It would also break any communication to your LAN (like, using > > network printer in your LAN)... > > Without a clear definition of what traffic is allowed (whitelist), I > don't see how this can be solved. Simply allowing e.g. 10.137.x.x is > also broad. Antispoofing rules should drop _only_ spoofed traffic - packets that use source IP that doesn't belong to its actual source. Antispoofing rules are not a place for other policy decisions. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZdhGYACgkQ24/THMrX 1yxF8gf+JqSFRbQtKg5wCgvduEelCO04duzdjZ5rHycbzwqZU/2aG1ywSpjbIyuH sIPhPRRvOuvTgJZ4P3Z5bWuOmxs+RG7W873v+KTuw8c3RRHrPHN0fGpM6oock428 bImO/UIC8RzIt7/4QnCfkZ+7n9kdEVE8EY8UxwAK1npCTKtvKdMJ9zTpcq+p8ZNr GzLEwGovVmrKuH8CWnBZw9wEjUwCio7RzAe33oLRT+wAB+wysICYwBi/mhAO1zHB F6o9AO33hG8Kg+l+sWeaJvlJGpsZ/8yyTxfj/F9iuL/dWMXciDGfD96ODTVB0Agz klovSFB9matrY0DGr+unXi+Lsa/msg== =h3oT -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/Zl2EZrbLlJU5UvMz%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Jun 01, 2024 at 04:04:33PM -, qubist wrote: > On Fri, 31 May 2024 23:18:51 +0200 Marek Marczykowski-Górecki wrote: > > > That's always the case. After all, your ingress rules are managed by > > userspace too. > > Sorry, I meant user-account malware, which (with passwordless root) can > instantly escalate to root and modify anything (interfaces, firewall). > Considering nothing sits between sys-net and the uplink(s), and it is a > firewall for itself, that makes it particularly vulnerable. I think you got the sys-net role wrong. sys-net is exactly the place where network devices are handled, including all the complexity like DHCP, WPA etc. It is the sandbox that may become compromised due to direct network access. It's the role of sys-firewall (among other things) to protect other qubes from outside network, including potentially compromised sys-net. That's why anti-spoofing rules are important on eth0 too. There is little point in trying to protect sys-net from itself... > > IMO static rules (the first option) is easier and more reliable (no > > need for that monitoring mechanism to keep working). > > Yes. > > However, it would be good to have some external control mechanism to > protect sys-net more efficiently. What can be done about that? See above. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZcuzkACgkQ24/THMrX 1yy4FAf8C68jkUTIyEo2/JeeyTUejw7K6nmk9jp6oBtDlpa2y5mcrwEmvEpjA7pG CfX0YUeCrtXLHB78NYHMSsJ3yD7pQvO8Z4+jlNH5i3J7CGaZksborCkina/HRREf KmvznahXOHr12LKmRpA+xd/yRLc0ZyeVfS99UVXTsOpiKUyi8zm2U+nLJmZZswmI 4t0G6QgAgu2Cg7ptZ2yGRZwYufEDdYGd6U5fGeCWB+zCfvIRslzma0taCblRvIgj 3+TfX55woxiSNlcFGy86YVfe/FdPOFARyPGzoDziR/ZV0lSdxGXW9pBTwAEZUC4B o7//R92gMDQuC8zafuicgq+ErwfiuA== =+fsi -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/Zly7OS5Ny4XgXfex%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, May 31, 2024 at 06:23:09PM -, qubist wrote: > On Thu, 30 May 2024 14:48:41 -0400 Demi Marie Obenour wrote: > > > Correct. > > Then: > > On Tue, 28 May 2024 16:49:51 -0400 Demi Marie Obenour wrote: > > > How do you plan to handle sys-net and VPN qubes? > > I can think of 2 options: > > 1. Stick with prerouting for those interfaces > > 2. Have some internal (in-qube) monitoring mechanism watching for new > interfaces and create chains based on such events. > > The problem with both options is that the firewall running inside > sys-net is just as reliable as sys-net being free from userspace > malware. That's always the case. After all, your ingress rules are managed by userspace too. IMO static rules (the first option) is easier and more reliable (no need for that monitoring mechanism to keep working). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZaPrsACgkQ24/THMrX 1yyJ8wgAg6pN3GfeqUYsXhnnflE/lNERsyo8DJ/6Y94OUZLFNZsQpFaM5vz0EAZn bbRsRE74qA7+1Q2+RRDyicgF0tK5Co1SHQ6FY4NjkNlk+eYBIv5+FKy/s8v34Pve tO+Pf3uIkELJKQrkAzHeatIw+FoqlmScVUWZ9s3e7Y+hruduj2iLP4CV3J6IiT15 TKkjxLUJMA+vDK9Q4pOiykSJAhHBfPQkDByJo7Hf9ZQvxd1T7cVwGrQYfdCa+fF5 F0NC1WGXJ1GG6qmx+Je81Cp0NYC+Dj/Prr82L04rDd9e3mIlCq42m/LKuU98OWF5 gvht3aTmWJ3hio8Ip3LbHfJ5+aKQow== =BNlh -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/Zlo-u9YsaJn348zs%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 23, 2024 at 04:30:46PM -, qubist wrote: > On Thu, 23 May 2024 15:53:39 +0200 Marek Marczykowski-Górecki wrote: > > > There will be some intentional discrepancies, that document describes > > a network using IPv6 autoconfiguration (where indeed packets like 133 > > and 134 are crucial), which we explicitly decide to not use. > > Thanks for explaining. I will get back to ICMPv6 later. > > > ping6: Warning: IPv6 link-local address on ICMP datagram socket > > may require ifname or scope-id => use: address% > > Interesting. I don't see this warning. Debian 12 template. > > > Build it based on the qube MAC address (which should be known to the > > vif script already)? Those antispoofing rules are meant only to > > prevent qube using IP that it's not allowed to use. So, for IPv6 a > > qube would be allowed to use either its "main" IPv6 or its link-local > > IPv6. Those rules are not meant to ensure any uniqueness, and > > link-local addresses don't need to be unique across different links. > > So, it is doable then. I will see how exactly. > > > Are you sure? The current implementation has this rule in prerouting: > > > > ip saddr @downstream counter drop > > > > and a matching "downstream" set. Your version removes that without > > equivalent replacement. > > I will test this again to double check. However, the way I understand > it: > > - Current implementation: the policy is accept and the device is not > defined explicitly (prerouting). That's why it is necessary to > explicitly drop saddr @downstream and to explicitly match the address > against the interface. Yes, but also note the antispoof chain (used for all vif+ interfaces) ends with a drop rule. So, for vif only explicitly allowed (source) IPs are accepted, others are blocked. And for eth0 it's the opposite: IPs used elsewhere are blocked and others are allowed. > - Proposed implementation: the policy is drop and the chain is bound to > the device (netdev). This means only the explicitly allowed IP source > addresses on the particular interface will be accepted, i.e. this is > the equivalent of the allowed map. As for downstream => no need to > define or drop a downstream set, because of the drop policy. Can you clarify your description of the downstream set here? I think you do need to have some drop rule somewhere. > Please let me know if I misunderstood anything. > > > Well, this is too broad, as for example sys-net is allowed to use its > > own IP to send packets down the network (like to sys-firewall or other > > qubes). [...] > > This list may work on internet-only router without any kind of LAN > > involved only. > > True. There is a reason why the Team Cymru adds a warning to know one's > network. > > It is possible to use a whitelist and a permissive rule before bogon > dropping, then process these particular packets later down the hooks. > Creating this whitelist has a usability burden, so perhaps it can be > defined through some kind of UI, similar to that for "Default and > service qubes" in global config. What do you say? That can be as some optional configuration user can opt-in to. I don't want this part in the default rules, even if user could adjust it make it work in their particular network. > > > > Sure: https://www.qubes-os.org/doc/automated-tests/ > > > > For network specifically, there is qubes.tests.integ.network > > > > and qubes.tests.integ.network_ipv6. > > > > > > Thanks. This is somewhat complicated for me. > > > > It is a bit (at least for the first time). The tl;dr is: > > What is the proper way to do it only inside a domU? I prefer not to > mess with dom0, as this is not a test-only system. Those tests are written to be launched from dom0. They create new qubes (with "test-" prefix) for performing the test, and then remove them afterwards. In fact, it operates on a copy of qubes.xml, the original one remains unchanged. Qubes other than with "test-" prefix are not changed. But it's not safe to do other stuff when a test is running. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmZQnSgACgkQ24/THMrX 1yyMQQf9Hmsfz1784CHnBqY5kqcRf25ONajWYRewDMdhyQ/cA9MhcUZ015/H/7WK sdysvQuTMHiFyBSApET+Op0KjpmIEeUgYaH7lxMOQ7anFB5ZSs+5w557gDik2Lb8 qMsgDtIy8G6WiEQoCOZb3AMdvEeM9ZnikGMy3NPYbLBdK0vg6v3tCqZqaiQxKbKe /HIRSA4OW4lw6Kr5IrZaS/voNl+oroAkL4JROKU6atJM7gtGLfv9pr3kU2RFVyX0 KfwuIJkd2MP6GSXp+pLl14ZDRrfzmCiAUH+NoeCjkiOdAZcLLu3wC5x8OsgxtcQR InlvcbbO3efRftm0BMG5pSqGbU+z3g== =5xvf -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/ZlCdKMy-i9m-e8Mr%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 23, 2024 at 12:33:02PM -, qubist wrote: > On Thu, 23 May 2024 12:04:18 +0200 Marek Marczykowski-Górecki wrote: > > > I mean one of them will drop packets that would be allowed by the > > other. So, no traffic will be allowed. > > Indeed. I will fix that. > > > Those are actually intentional, we don't do dynamic IP configuration > > on purpose (attack surface reduction), and even if for some reason > > one VM would try to sent such packets (could be an attempt to change > > sys-firewall's configuration by one of AppVMs...), they should be > > blocked. Same for Redirect. > > According to RFC 4890 section 4.4.1 (local configuration traffic), > router advertisement messages (ICMPv6 type 134) must not be dropped by > the end host (Qubes drops them). In 4.3.3 (transit traffic), they list > both types (134 and 137) as "Traffic That Will Be Dropped Anyway -- No > Special Attention Needed" and in the bash script in the appendix they > actually drop them + quite a few other types - traffic which Qubes > allows. So, except for type 137 (redirect), there is some significant > discrepancy between these recommendations and Qubes. There will be some intentional discrepancies, that document describes a network using IPv6 autoconfiguration (where indeed packets like 133 and 134 are crucial), which we explicitly decide to not use. > That, of course, is off-topic we can discuss later. I am just > mentioning it along the lines of what should/not be dropped by the > antispoof and its potential effect on IPv6. > > > Still, link-local addresses shouldn't be used to communicate between > > two different links. > > If I am reading the RFC correctly, they are not used for communicating > (i.e. fully-fledged data transfer), but rather for establishing > communication. I am not a network expert, so I am not closely familiar > with all the inner workings of IPv6. > > Section 6.1.2 of RFC 4861 says: > > - IP Source Address is a link-local address. Routers must use > their link-local address as the source for Router Advertisement > and Redirect messages so that hosts can uniquely identify > routers. > > Assuming sys-firewall is the router, perhaps there needs to be a way to > advertise it. RD etc shouldn't really be needed in our case. But neighbor discovery might. > However, that is a data-collision problem because all > qubes have the same link-local address and the node would confuse its > own with that of sys-firewall. No? No, link-local addresses don't need to be globally unique, they need to be unique only within a scope of a _single_ link (eth0<->vif pair in this case). Linux (or any other routing-capable OS for that matter) needs to consider which interface to use for which control packet anyway - - in fact, I think it's not valid to target link local address without explicit interface name (on which link you want it to be). For example ping warns about it: $ ping6 fe80::fcff::feff: ping6: Warning: IPv6 link-local address on ICMP datagram socket may require ifname or scope-id => use: address% > > That said, allowing specific link-local address in the antispoofing > > rules (and later filter undesirable packets using normal rules) might > > be a good idea. > > My thoughts too. The question is what is the appropriate way to do > this, considering that currently all MAC addresses are the same => all > link-local IPv6 addresses too. IOW, what would be the mechanism of > getting the specific link-local address, so that it can be used in the > antispoofing rules? Build it based on the qube MAC address (which should be known to the vif script already)? Those antispoofing rules are meant only to prevent qube using IP that it's not allowed to use. So, for IPv6 a qube would be allowed to use either its "main" IPv6 or its link-local IPv6. Those rules are not meant to ensure any uniqueness, and link-local addresses don't need to be unique across different links. > > > Are you suggesting that we should antispoof eth0 too? > > > > Yes, the change you propose should not regress one of the issues > > classified as security bugs before... > > It does not propose that. It does not allow traffic which is blocked by > current implementation. Are you sure? The current implementation has this rule in prerouting: ip saddr @downstream counter drop and a matching "downstream" set. Your version removes that without equivalent replacement. > > For example, sys-net should not be able to pretend to be one of your > > AppVMs. That's especially relevant if you'd configure sys-firewa
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 23, 2024 at 09:39:55AM -, qubist wrote:
> On Thu, 23 May 2024 02:08:20 +0200 Marek Marczykowski-Górecki wrote:
>
> > As for the implementation, few remarks:
> > - - you create separate chain per IP, each with policy drop - it will
> > fail for multiple IPs (for example both IPv4 and IPv6)
>
> What do you mean by fail?
I mean one of them will drop packets that would be allowed by the
other. So, no traffic will be allowed.
> The suggested implementation successfully creates separate
> uniqely-named chains for the IPv4 and IPv6 addresses of the same vif
> and automatically removes them upon vif's disconnect. Example:
>
> # nft list table netdev antispoof
> table netdev antispoof {
> chain antispoof-vif16-0-10-137-0-91 {
> type filter hook ingress device "vif16.0" priority -500;
> policy drop;
> iifgroup 2 ip saddr 10.137.0.91 accept
> counter packets 0 bytes 0
> }
>
> chain antispoof-vif16-0-fd09-24ef-4179-a89-5b {
> type filter hook ingress device "vif16.0" priority -500;
> policy drop;
> iifgroup 2 ip6 saddr fd09:24ef:4179::a89:5b accept
> counter packets 8 bytes 640
> }
> }
>
> > - it should be one chain with possibly multiple rules (or one with a
> > set?)
>
> Using a single chain for all vifs and IP addresses is quite challenging
> for the following reasons:
No, I mean one chain per vif (but for all its IPs), instead of one per
IP.
(...)
> There is something else that bothers me, which I would like to discuss
> with you:
>
> While working on a more meticulous IPv6 filtering, I noticed the
> following. This is both about existing implementation, as well as about
> the suggested one (which simply inherits the algorithm):
>
> Certain ICMPv6 messages (Router Advertisement and Redirect), currently
> cannot transit the firewall,
Those are actually intentional, we don't do dynamic IP configuration on
purpose (attack surface reduction), and even if for some reason one VM
would try to sent such packets (could be an attempt to change
sys-firewall's configuration by one of AppVMs...), they should be
blocked. Same for Redirect.
> because, as per RFC 4861, they MUST have a
> link-local source address. Considering the ${ip} address list, sent by
> Xen to the script, does not contain these addresses, the antispoofing
> mechanism blocks the possibility for creating a fully functional local
> IPv6 network between 2 or more qubes without hacking the nftables chain
> structure and custom scripting to detect vif name etc. This BTW makes
> the existing _icmpv6 chain simply unreachable by any external packet.
The link-local traffic should not be forwarded anyway. And definitely
shouldn't be used to communicate between two separate qubes.
> I also notice that all qubes receive the same link-local address for
> eth0:
>
> inet6 fe80::216:3eff:fe5e:6c00/64
>
> obviously based on the same MAC address they receive too.
Yes, but the MAC address can be changed (see "mac" property). And the
vif script should have access to it too I think.
> This practically means that to distinguish packets during filtering,
> matching of the interface name (which is dynamic) is also required and
> that makes things fairly complicated if qube A filters traffic from
> qube B. This seems similar to issue #8833, just for a different
> component.
>
> So, I wonder what is the correct approach in regards to that. On one
> hand, it is very much desired to disallow qube-to-qube network chatter
> by default, even if the qubes have IPv6 enabled. On the other, there
> needs to be a mechanism allowing the user to easily configure a custom
> IPv6 qubes-LAN.
Still, link-local addresses shouldn't be used to communicate between two
different links. There may be some cases where app-qube <-> sys-firewall
communication is affected by the unexpected filtering of all link-local
traffic, but I don't think it affects anything in practice (haven't seen
any issues). That said, allowing specific link-local address in the
antispoofing rules (and later filter undesirable packets using normal
rules) might be a good idea.
> I would very much like to know what you think about that.
>
> > - - "downstream" map is gone (without a replacement using the new
> > method), opening spoofing on eth0 - see QSB-056 for details:
> > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-056-2019.txt
>
> Are you suggesting that we should antispoof eth0 too?
Yes, the change you propose should not regress one of the issues
classified as secur
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sat, Apr 27, 2024 at 01:52:19PM -, qubist wrote:
> On Tue, 23 Apr 2024 12:04:22 +0200 Marek Marczykowski-Górecki wrote:
>
> > Have you measured it? I'd say it's up to ones who propose a change to
> > justify it.
>
> Now, I have.
>
> Setup:
>
> 2 VMs: firewall and client (vif interface). TCP and UDP port 1000 is
> explicitly open on firewall's input for the purpose of testing.
>
> Testing procedure:
>
> - run a test for at least 1 minute
> - note load average in firewall VM
> - wait 1 minute before next test
>
> ==
>
> Original Qubes firewall
> ---
>
> ### Spoof
>
> # time (timeout 65s hping3 10.137.0.88 --flood --spoof 10.137.0.88)
> HPING 10.137.0.88 (eth0 10.137.0.88): NO FLAGS are set, 40 headers + 0 data
> bytes
> hping in flood mode, no replies will be shown
>
> --- 10.137.0.88 hping statistic ---
> 14397433 packets transmitted, 0 packets received, 100% packet loss
> round-trip min/avg/max = 0.0/0.0/0.0 ms
>
> real1m5.015s
> user0m6.268s
> sys 0m47.634s
>
> load average: 0.21, 0.07, 0.02
>
> --
>
> ### iperf3 between the 2 VMs
>
> # iperf3 -c 10.137.0.88 -p 1000 -t 65
> ...
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-65.00 sec 37.4 GBytes 4.94 Gbits/sec 1158 sender
> [ 5] 0.00-65.01 sec 37.4 GBytes 4.94 Gbits/sec receiver
>
> load average: 1.44, 0.49, 0.17
>
>
> ==
>
> Antispoof in ingress
>
>
> This is what the modified vif-route-qubes creates. The policy is 'drop'
> because only traffic from the original (non-spoofed) IP address is
> allowed anyway and the chain has no other function:
>
> # nft list table netdev antispoof
> table netdev antispoof {
> chain antispoof-vif19-0-10-137-0-11 {
> type filter hook ingress device "vif19.0" priority -500; policy
> drop;
> iifgroup 2 ip saddr 10.137.0.11 accept
> counter packets 13 bytes 796
> }
> }
>
> Before testing, remove unused rules too:
>
> # nft flush chain ip qubes antispoof
> # nft flush chain ip6 qubes antispoof
> # nft flush chain ip qubes prerouting
> # nft flush chain ip6 qubes prerouting
>
>
> ### Spoof
>
> # time (timeout 65s hping3 10.137.0.88 --flood --spoof 10.137.0.88)
> HPING 10.137.0.88 (eth0 10.137.0.88): NO FLAGS are set, 40 headers + 0 data
> bytes
> hping in flood mode, no replies will be shown
>
> --- 10.137.0.88 hping statistic ---
> 13443086 packets transmitted, 0 packets received, 100% packet loss
> round-trip min/avg/max = 0.0/0.0/0.0 ms
>
> real1m5.016s
> user0m5.999s
> sys 0m47.699s
>
> load average: 0.03, 0.13, 0.09
>
> --
>
> ### iperf3 between the 2 VMs
>
> # iperf3 -c 10.137.0.88 -p 1000 -t 65
> ...
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-65.00 sec 37.4 GBytes 4.95 Gbits/sec 887 sender
> [ 5] 0.00-65.01 sec 37.4 GBytes 4.95 Gbits/sec receiver
>
> load average: 1.21, 0.47, 0.22
>
> ==
>
> Side by side summary:
>
> Spoof:
>
> current Qubes firewall: load average: 0.21
> antispoof in ingress: load average: 0.03
>
>
> iperf3:
>
> current Qubes firewall: 4.94 Gbits/sec, load average: 1.44
> antispoof in ingress: 4.95 Gbits/sec, load average: 1.21
Ok, so it does improve performance a bit. The scenario of flooding with
spoofed traffic is not very realistic, but does show the impact. But
even on more realistic scenario of allowed traffic, the difference is
noticeable. IMO worth changing.
> ==
>
> The code:
>
> # This is the new /etc/qubes/qubes-antispoof.nft:
>
> #!/usr/sbin/nft -f
>
> table netdev antispoof
> delete table netdev antispoof
>
> table netdev antispoof {
> }
>
> I am attaching the modified vif-route-qubes.
As for the implementation, few remarks:
- - you create separate chain per IP, each with policy drop - it will
fail for multiple IPs (for example both IPv4 and IPv6) - it should be
o
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnqGkACgkQ24/THMrX 1ywg1gf9HJQJnkXOOXV/a7ttUlwm5lINhwZ7KSAqOqCX8rklWZqeVtal4ywDeld6 1G9jpL7u+yq3qZZgPYJPOoEK5VNfI5VTDFICN9xrelwJDZsZvLlrWc9qU4ddB+FW yEYcCoEGsK9GGYrieFhBQaVOtmSlcvyWVnfhLaHdiL8JfL0GTx8DiF7ZxJbDM28h 7VAdPJPsivunchjKdww+d5gvpFEv3ISxOR790EL8nOCmIypBpJ7cEvmz7/qF9DY1 iyggJ340yYHVyeRu9aHG2/KfHT04GFcHqN2YQBj/f3xj9H07Qm77DVD4mM59d7h9 ktWLlI0YQmGgNMXPeEk7Wa416g6o+w== =Icq+ -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/ZieoaZRUcoEiKoz_%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:57:14AM -, qubist wrote: > On Tue, 23 Apr 2024 13:42:25 +0200 Marek Marczykowski-Górecki wrote: > > > xendriverdomain daemon (xl devd), when the vif interface is > > created/removed. > > Thanks. > > > I'd use some packet generator, maybe even ping (or nping) will be > > enough. You can easily try spoofing by changing IP inside some test > > VM. > > Well, I have been using hping3 for spoofing but it doesn't provide a > measure. I thought that by measure you mean something along the lines > of network throughput during a heavy spoofing load. I'd simply generate some traffic and observe CPU load in the firewall vm. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnpzAACgkQ24/THMrX 1yz1BAf/TUImu5wA+HKsonG0hRnTZCxBQ57/oZn2H/8fX8k6B84a9USBaZghygvD G41usqvZM/9mBUCMNk1o0ayCIseYOwsvp2bPOLX9WmSNMamL+rPCKcFTTQ6Jmwnv XPGV//UQ9EwwWYuSf4ApeTO3NgeNI/NThhLyq99WUxz+CkNqBuPI4TZ9VtEmhAZy KkVNT/PDCIpv09l8gjm8NIwkSAzsbT1wZTYZgd2ygIwZdz+ClsqPwlpZZ8R41YGy YYiqgSxXAHE89foMzAYvq4UmaOrCReJBChJpwyPwxVLeBBqqyYD0pMe14Gmw7LJA DE4VhNZA9sBmwHPvD9uvAahyqodWXA== =9g30 -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/ZienMCTD80N6ftZV%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:22:06AM -, qubist wrote: > On Tue, 23 Apr 2024 12:20:57 +0200 Marek Marczykowski-Górecki wrote: > > > You mean using something else than vif-route-qubes network script (or > > some other way to reconfigure vif interfaces)? > > I don't know if I mean that as I have not studied that script > thoroughly. What I mean is in the general sense: the assumption that > MAC addresses should be unique within a LAN. I don't know how that is > related to bridge/no-bridge. Ok, so the answer is in my previous email - on the setup we use, each VM has its own subnet. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnnywACgkQ24/THMrX 1yzpQwf5AdjX3W7HnDGP8KUv4cUHRh1Wt6yjFLLS0gl23LYof1G2CNLl/cW5yD8z bexAA4QfRCqXlslG8CJrMr9WuIY3cqjTHdtF3kUFrhA3DgSTHgD+nk9eijVRyvTL yTKfWXgfjmTQfz8DgbF4GtdZ2QNIDwgu3fN0O34YXwpnQBROmZzPk/E/ByciMenz rZhgSYaCGcJYQjImorKWqVHMS4no5xHnT1KpyOMMzFgYIn3jmIo8XBrX+E7KPrg5 4C3vVEE629s1FVLKJoCnHgCDDLJhgz27HravlS63ExEsVHdqo4UHgNcJIM7wgOtK GClKQo4Qr2et6bjt2CBqc6WDB1yWrg== =q2ME -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/ZiefLOgyjYBpv1XR%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 11:16:56AM -, qubist wrote: > On Tue, 23 Apr 2024 12:04:22 +0200 Marek Marczykowski-Górecki wrote: > > > Care to open a pull request then? > > A few things: > > 1. The customizations I am working on are atomic nftables tables, > chains and rules. So far, they work fine independently and along with > the current default firewall. > > 2. I still don't know how to work with git efficiently, so this "pull > request" is something I need to learn about first. All I know so far is > how to create a project and commit changes. > > 3. My firewall work (which involves other improvements, I hope) is > still not complete. As soon as it is, I would gladly share it. > > > This is done in the vif hotplug script: > > https://github.com/QubesOS/qubes-core-agent-linux/blob/main/network/vif-route-qubes#L222-L223 > > Thanks! Bash is fine for me, so I will see what modification works > best. What calls that script BTW? xendriverdomain daemon (xl devd), when the vif interface is created/removed. > > Have you measured it? > > Not yet. At least not in a way deserving to be called measurement. All > I have done is to trace the result and see that ingress works with less > steps. If you know a good way to measure it correctly, please let me > know. I'd use some packet generator, maybe even ping (or nping) will be enough. You can easily try spoofing by changing IP inside some test VM. > > I'd say it's up to ones who propose a change to justify it. > > Of course. > > > Or do you mean moving just "antispoof" chain out of "prerouting" and > > have it hooked directly? > > I am testing my stuff in the netdev with priority -500. However, > ingress is available in prerouting too, so that move might work as well. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnnqEACgkQ24/THMrX 1ywroAf/U0Iq2WsIFs1HPv/PGobjCdEz5cSFsL+4fWACYydi+Cqtj8EOQmc1cRh/ ei9xYpGcQYFD69/suZZuostkb87LIuwNsA/jJ2NDQjnCdM1G/i0Z/lUoPAuNNb07 h3csaDGQPWtKuLAM30ADsVSa+dneAyu9tkK+xAOI+Kq8R+UjkVPr1Dxdnf5RXHSL niFIicJB6U9+cVCO8jr/3O4DgYp8xf1GsL6uCXx9bPgO25R57Y+Mcga5Jam1SeG7 P5f3REk91kiZ2BZG5kmlfg9ipAE/Fyx9y4QLcz9fcafzwu17NFZlP+jRDShqLKAx ijh44R63lS1nT5TiPJFYLbsrMmtQEg== =xJVU -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/ZieeocPY_0fxKw5M%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 05:33:14AM -, qubist wrote: > On Mon, 22 Apr 2024 21:24:36 +0200 Marek Marczykowski-Górecki wrote: > > > It's about the pixel count as seen by the applications, which may not > > necessarily be the display resolution if scaling is involved. > > Are you saying that scaling means preserving the original pixel count > (i.e. apps draw on the original, unscaled canvas) and then the whole > thing is scaled down in real time? Is this how xrandr works? Let me clarify it this way: when using scaling, you will see for example eDP-1 connected primary 1920x1080+0+1200 (normal left inverted right x axis y axis) 309mm x 174mm 2560x1440 60.00*+ 59.9959.9959.9659.95 ... Use the 1920x1080 in the formula, not 2560x1440 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnjHMACgkQ24/THMrX 1yy6PwgAiyBrVYEnreVgRyBq6/NNQUZR8rd3b5rjzixDdZMRrNfPZ7F1rX+ww+jn c3iROIcepGTzPogM7bBQJpco+Qa5jEcp5mfyN6z62D8IBvP6hZZNwcVY80o3lCzZ DhvVuvz49bA00CW98gppo9SjNT9v15YKW+NVVim7qtPsMTAglz1tNx9hbnsCtB9m oP2k816/AAbSvdaqAbcYqjP/T8Vcety+k3zH5bZ2ZAooQTXulZ49b74inl9nUFWJ KzKtPY7zkw+cyYwwYIVEpNSMkEePMhHUHaeQHgN7wsMHuP91SD2SB4DthvujIuqq BB9gOHSF8K5Vt2RJtjiDsG5EMW6hAQ== =Foc3 -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/ZieMc8Qbi8JosCNr%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 10:15:56AM -, qubist wrote: > On Tue, 23 Apr 2024 12:07:12 +0200 Marek Marczykowski-Górecki wrote: > > > Yes, the key part is "on the same subnet". Each VM-VM link is > > effectively a separate "subnet" with just two endpoints (eth0 > > interface in one VM and vif interface in the other). We do not use > > bridges. > > I see. What about the case of a custom virtual LAN, involving multiple > VMs (still routed by sys-firewall)? Wouldn't same MACs create a problem? You mean using something else than vif-route-qubes network script (or some other way to reconfigure vif interfaces)? I don't think we allow to choose network script, and that's the place (libvirt config) where mac address is set too. So, if you change one, you can very well change the other too. > > If you like, you can set any mac address using qvm-prefs, and here you > > don't need to worry about its uniqueness :) > > Is this what one must do for the case described above? I guess so. But we don't really support bridged configuration. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYni4kACgkQ24/THMrX 1yw9Sgf+NOHAGPeFQsau37qM4QOerQKJUHzUxrxVAtGKUonXIrGVkGCU5EnQEAbb iSMsObPO90kR5l+vNKCZt+xOAsMp9KWUSZ/EnwIwklSo5VNRPw0s4PexFD+etosH gW9UMopmhfder4XwQ6IPnK4mSITpuMGZDecOJJ2xLnGaQHaOBOQJ5FihWQxN3bEQ 9oXVGEwMvy1EhbuWBJR9/XFRqhys1jSsVKaI5agseiMnZbjO39XMpSy83V2FXI0L UmFg4uWwaQJ+Z1DqFJDPz5QvBWNbx4pteMZJh2NhNUVbA+VuxdnNUsPs/w8/vFiE abqln1OBrTP5zJVKTb2S22imt/EC8A== =G/a6 -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/ZieLiQs-4WClOsk_%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 08:45:36AM -, qubist wrote: > Thanks. > > What about MAC addresses? Why do all VMs use the same one? > Aren't MAC addresses required to be unique on the same subnet? Yes, the key part is "on the same subnet". Each VM-VM link is effectively a separate "subnet" with just two endpoints (eth0 interface in one VM and vif interface in the other). We do not use bridges. If you like, you can set any mac address using qvm-prefs, and here you don't need to worry about its uniqueness :) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYniFAACgkQ24/THMrX 1ywSuwgAk2YpFfGWkH7umkloeLwBuBo+IlNu5AxjP7gji2WSQZpZKLW4hDJAKO/K +c/5zbvh/TORyT2/4KB/RxpilvpRsgGLPdFf8f36coUGywDu8Gk3EXtAG+r6hPyY ryVXD3UEj54F5+MEYmlRU1GfGLOFJ9u/WG7tDDnPDs4EmIgLzJWbQUswnXTfWmyP fHuT3gJW9+AcJ1ADYpupbT271YYv2mbNBL3mWOt0d9F2cBSWPbDKTin92O9/EzLi cd2T0OCoUhPcF8F8P5ZT/rzuCe2K+Y1ovoGSsy4Wr2wjaZVxEF4ZuuSaKLtFQKUm nnKZa2vOzaOBMPKW6F45XjC0MxaNcg== =mTeN -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/ZieIUMYXja6mPPVk%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Apr 23, 2024 at 08:40:04AM -, qubist wrote: > On Mon, 22 Apr 2024 22:41:40 +0200 Marek Marczykowski-Górecki wrote: > > > The "antispoof" chain is hooked via the "raw" priority, which happens > > before all kind of connection tracking, routing etc, basically as > > early as firewall can see whole IP packets (not for example only their > > fragments). > > I can see how it is done but why would one need to (potentially) > defragment the spoofed packets first just to drop them later? How does > that match the mentioned principle? > > > Theoretically it might be moved a bit earlier, > > What do you mean theoretically? It can be done practically. I have done > it and it works. Care to open a pull request then? > What I am lacking is the mechanism of dynamically > adding interface . address paired elements to the set, which comes with > Qubes This is done in the vif hotplug script: https://github.com/QubesOS/qubes-core-agent-linux/blob/main/network/vif-route-qubes#L222-L223 > , so my approach is not as flexible as the original, e.g. I can > drop hosts "pretending to be me" and bogons but that's pretty much all. > > > but I don't think it saves much processing, > > Have you made any actual tests/comparisons? In a high speed attack > (many spoofed packets) it may turn out significant. Have you measured it? I'd say it's up to ones who propose a change to justify it. (but, if the change has no downsides, I'm okay with accepting it without detailed benchmark too) > > but on the other hand you may run into some issues since not all > > packet fields are available at this stage yet. > > What issues? Which fields are necessary to drop spoofed packets? For antispoofing probably none. But other things can be added to the "prerouting" chain. Or do you mean moving just "antispoof" chain out of "prerouting" and have it hooked directly? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYnh6YACgkQ24/THMrX 1yyVEwf9HaVqh1fIgTeuYoTE6WK76O8CKSJaXIkm13b8br22OnvwhdzMlD74b/Y6 0nJloGncWtzn2mkGQsSH1azQTa8aroZqzqCa5GnnfiAPyXvDl4q/nM3bzw+V+SRE wISQolnH/0nPhsvUENGj2nJGVG9fR6izFxIfj/gO+6dro1GRANkHb2m2F/GIsRKu ORw5MIcprWb7t1aCrxPkCDArFt3NAsg53uxTZLsO1Tr/nH6T5GxRiPsE8U1T7pcj HWctIVJXh3JYUi4mrVVjIz9GhLSFI8Q9LykBJ+EG7vcabn5D+GN8/n5ycC1Cokx2 eJLrnfZHGQzgZ4BuN26tjQ9U0I7UDA== =2DVw -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/ZieHpnww4gZ3MFYh%40mail-itl.
Re: [qubes-devel] Firewall antispoofing in ingress hook
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 07:26:30PM -, qubist wrote: > Hi, > > With the current firewall, a spoofed packet can travel all the way to > the ip/ip6 hook, where it is dropped. > > Considering the general security principle to stop attacks as far as > possible, why is it not dropped early in the ingress hook instead, thus > also saving additional CPU cycles? The "antispoof" chain is hooked via the "raw" priority, which happens before all kind of connection tracking, routing etc, basically as early as firewall can see whole IP packets (not for example only their fragments). Theoretically it might be moved a bit earlier, but I don't think it saves much processing, but on the other hand you may run into some issues since not all packet fields are available at this stage yet. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmy4QACgkQ24/THMrX 1yx2KQf/coLIf6whMj5JfoCF4X3E+x0liALkjPNNC7GART8HkZzCA+9w+We6bpg6 09VOWEEmMPa7PNjEFKg+frMAWT2gCFye0civCucSvmVtSmzRpZL3eWPmWZPlj8pt ITPE79fyVXBEIsvuKQaZloGFeyINQQSW64Szf+k+sWy+uTrcyV6Kx0tWpDi5KTVK TSc28ujclSWRcDCCo836lMLmd4NgBZ63C0MAdLQfzP97wwzqbFrj7FBT+r41B/ES QZE0W2zanxmA/DDoP7NOZ4BjHFSk62ueQ8xgeAyQRdNFFDwVNv2crRtjlmgolZ5z 9RgNwR9cD4/EDxhM7aP0D+fkurnaUg== =98ms -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/ZibLhA8hJuYL9ZLJ%40mail-itl.
Re: [qubes-devel] What ensures the lack of VM IP address duplicates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 07:20:08PM -, qubist wrote: > Hi, > > Which particular code is responsible for ensuring that 2 or more VMs > can never have the same IP (or IPv6) address? They are generated by default based on qubes VM ID (qid)[1], which are unique. You can see it on `qvm-ls -O name,qid,ip`. But you can also set the IP explicitly (via qvm-prefs), and then it's up to you to avoid conflicts. BTW, it's also possible hide VM's "real" IP from the VM itself using a bit of NAT magic. You can set it with `qvm-features VMNAME net.fake-ip 1.2.3.4` (or any other IP). See qvm-features man page for details. The VM will see own address as 1.2.3.4. Address set this way does not need to be unique - you can have a set of VMs that all think they have the same IP (but still, the address set in the "ip" property needs to be unique). [1] https://github.com/QubesOS/qubes-core-admin/blob/main/qubes/vm/mix/net.py#L192 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmu+EACgkQ24/THMrX 1yzM1QgAio17EE6Vyh2Q5cbbbWewEcKzslW7WugCHlciSr9Z7BU2JWnDv6lLvvp3 4u1wXpkWHK8Ug90MTwzoOykX7f7hHBxtZBu5Z0iewKzKzZiMNBhPIGE6lcdva8Dx Arl+wdoXN+DPjhAxkC/DRlMHA6gKSNEZSQXw8G2cjpxTGVpp/Gpjmt9R08EFFlbh MR9RLPxT/nugz5nhKl2TTdsko+pC2FZlBGpk6czVErkbE24iAnyxG6gr1WX3/qk1 chXi3BOSQgNUUp52tc3BXPhgOcCFfwLLkxKN/IEjSXl8D7fkvinTpvHs1Kyzs/9x zyT5JTduRDmIYHGNQ+rYsBQH7cUmEg== =HCu4 -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/Zia74U6xixfKfR9D%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 05:18:28PM -, qubist wrote: > Thanks. Had a closer look now. > > On Mon, 22 Apr 2024 18:42:16 +0200 Marek Marczykowski-Górecki wrote: > > > What matters is the pixel count, not pixel size. > > But which pixel count? > > The pixel count reported by xrandr with the 2 screens side by side (4K > primary) is: > > user@dom0:~ > xrandr --verbose | grep "Screen 0" | sed -e 's/.*current//' -e > 's/\,.*//' > 7680 x 2160 (which means 64800 KiB for gui-videoram-min) > > which is different from 3840 * 2160 + 1920 * 1080 (i.e. 48600 KiB). > > So, the 2 formulas in the doc still give different result and it is not > clear which one is correct. It's about the pixel count as seen by the applications, which may not necessarily be the display resolution if scaling is involved. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmuXQACgkQ24/THMrX 1yx0zgf/UbIX8w0XBGy0iqObsS8A/jWjtj4c3aCvLCgWfxhnWyUjyyyKZYMpEwqT lT98KrrFUynnjCW0c3ywzuR9T2ESV7NQqsoj85tRSLEnDHAG4wjgw0x6RyMbqPrN undP4RWV/sdO60a8u3t55lfxxnnbjeXmaNHNWgNtRiqAixjJiFbhlJ3FT8/NYcd9 YJQ67RRDj4GdPbCQptzYlvoepTiQ3nxkaKakPv92/tKGntIDvfyVz3tiyiSnY+zD AMXV+TIAB6pf26mwpja551WyEq3eB3iNzFIpSrrKAPD5I5kHrlNfrrqPoh+OdN5T dnugSim2/6x2ku7XP7ekW+vYapl4gA== =+ylP -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/Zia5dA7uLNN8MDbJ%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 04:37:54PM -, qubist wrote: > On Mon, 22 Apr 2024 15:48:02 +0200 Marek Marczykowski-Górecki wrote: > > > If you don't set the value at all, VM will allocate based on currently > > connected displays. > > Hm. This raises a few questions: > > 1. Does it mean https://www.qubes-os.org/doc/gui-configuration/ is > irrelevant/outdated? No, please read the text leading to the formula, not just the formula itself... > 2. What happens with allocation if one switches from one display setup > to another while VM(s) are running?o Read that page... > 3. What about headless VMs (no guivm)? Is video memory allocated for > them too? (thus wasting resources) No. > 4. A somewhat difficult setup: > > Due to both displays having different resolutions and because I have > been unable to find a way to set different DPI per display, currently, > it is necessary to do this when switching to the only-2K display or > dual-screen setup: > > xrandr --output DP-2 --scale 2x2 > > Without that, everything on the 2K screen is overscaled and working > side-by-side is not possible. > > Does that somehow influence the formula in the docs (because > effectively the pixels on DP-2 become x4 less)? What matters is the pixel count, not pixel size. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmk2gACgkQ24/THMrX 1yxhQgf/aUFI437ylLXN16RLu64tg+wUPR6xt8Vl/xwNKdZzW5HjEp7Beuo/ew3A oa1ZdP0mIZTV/bRXRNw0wjnFYgNrb58Eq+N7whw0z5l61ZCrojIRDY7/yfOzPh9+ +x7uCUEYwytpsRftjZUwzyeq2jza3GeMup0Ql5f4C6nEOcDcJDqbGvqnx3h1V3yq DExNy+3x2M9Ag/ttWbvsHc0+uqEl+Z/tzsPrjrTHFMALwlQWn7q7QHKoHeWtkc9J 2YBWLcUeWoGV3fsZBk+hTT1DW81/buqH1ABnymVPYEQXzhJXHV868G+bahpZIEK7 yJICgk1FMilShTsIpglERVdSAr/2Zg== =XwaZ -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/ZiaTaLen3bvxg85m%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 01:23:11PM -, qubist wrote: > Thanks for explaining. > > If only one of the displays is currently in use (and the whole desktop > fits in it), does it make sense to reduce the the allocated video RAM > to its requirements only (the qvm feature value)? > > I am asking because this can be done through a simple script in dom0, > triggered by a shortcut key (e.g. one switches from display1 to > display2, or to dual screen and back). If you don't set the value at all, VM will allocate based on currently connected displays. But changing the value requires restarting relevant VMs, so if you care about connecting external display without restarting all VMs, then no, you cannot lower it. But if you don't care about the need to restart, then you may not need to set the value manually at all. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmapIACgkQ24/THMrX 1yy7IggAi7ksQ5QEG3hrwZIAvrZWeC3gvpfhw0iyqXxpnWo87IgfjSeElT5QHh8H 8WCQmj3BahldgcSfWvJeGJ5wuPiB+qpVQeX5emydC2XfENmyG8b3lfrVIn14uxvg 4rCW6GbRP24UZmU0Ed+1WRGE/4MkFjMfTg+na8NUE7mwUJJQOoHwoJzDjvuf4/oh vm1wzwwvugieV+EsCA4c+a/qfrYWFMxwqXQbv85OzLiSCDMKW4jSf/DX4Jw2KUHn 4AJh7hy3lBcME6bjLbq+Cippkbm7xb8Jlu87uUbRIKCiJZdW5VOPuOUe8CTOH+yQ 86oB1V6CxQqMw+3cEQeC01vjS3+9ow== =am77 -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/ZiZqkrqODC-N-TWu%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 01:01:55PM -, qubist wrote: > On Mon, 22 Apr 2024 13:31:03 +0200 Marek Marczykowski-Górecki wrote: > > > VMs do not see nor care what display is connected. > > But what I am pasting is from dom0. Or are you saying it doesn't see it > either? The formula on https://www.qubes-os.org/doc/gui-configuration/#video-ram-adjustment-for-high-resolution-displays is about informing VMs how much memory they need to allocate for video ram. I know it's a bit unintuitive as the value is set on dom0, but it's because the value on dom0 is the default for all VMs, so you can set it once instead of on every VM separately. > It is still not clear whether if it is possible to use 10/30-bit color. You can use such display, but VMs won't see wider color space, they will still use 8 bits per color (and dom0 will covert to whatever format your display uses). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmY7sACgkQ24/THMrX 1yw2SwgAie0fWITCQGUo2kOFHJePtSRF1FNAHpEe/09MNSPvdk8YXmSLhtL7AAtX L7c2kpQt21TeA6v871T4mc43pkWVY/5Q7utnQamP0gtHx/8lmXQBfZJb96J1bIWy v8e9ek/Z/2fbHD4xdYyKnfOvVon7QqTO02bNBH9cnuD+iPEzjXpe7fsIU9hZZB8u aKFcduKCuA6kGvUcE6FUzRGeRAF1JYAyr4rUBNlSnLjZ5rTz28UfBQmpgDTHoAyF nXH8aw3TfiD7DOugJGpxWph5pLXe5QYj2Pk1wuApPLL1BX4XUWstNLW/jQwrvK8G ohuSCGRZzGG1fu45Vcvcc2UcRa/RmQ== =wGMh -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/ZiZju9bCqh64p0Dc%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 22, 2024 at 10:38:56AM -, qubist wrote: > On Mon, 22 Apr 2024 00:01:30 +0200 Marek Marczykowski-Górecki wrote: > > > It doesn't matter what your display is using, the memory allocated in > > VM for the frame buffer is 32-bits per pixel. > > When using a 4K 10-bit display (note the bpp): > > root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info > pipe src=3840x2160+0+0, dither=no, bpp=30 > pipe src=0x0+0+0, dither=no, bpp=0 > pipe src=0x0+0+0, dither=no, bpp=0 > > When using a 2K 8-bit display: > > root@dom0:~ # grep bpp /sys/kernel/debug/dri/0/i915_display_info > pipe src=0x0+0+0, dither=no, bpp=0 > pipe src=1920x1080+0+0, dither=no, bpp=24 > pipe src=0x0+0+0, dither=no, bpp=0 > > Also, according to 'xrandr --verbose", max bpc is 12. > > How do you read this? > > If it is always 32 bits, it would mean 2-bit alpha for 10-bit display. > Or does Qubes OS even support 10/30-bit color? VMs do not see nor care what display is connected. From the VM point of view it's always 32 bits per pixel (3x8 + 8 padding, as alpha is not supported). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYmSncACgkQ24/THMrX 1yxtzwf8CShXlR8j4651qFqPti6tHfL2gs9Jred4yvi3xdoZ9KLnGMZYUFoR/QN/ yZlfklge0foJHDDpOUcB+Q+Ku2SfS0Did6yUMaHQVwGH1X8zXkcLYOwIICOR2FDv 9uwdqpLEVLZK3Qmsu9RDGSs83dlub1KXzWtPaW1eMfDbxrYj5OJGjPpqsB4dT4MI YroowdXAV3+7pWt7Snb6MhRMgUKRHrXlxjLa5yl+CKZaB0eIfDMh2Dbs+0X581S9 z0j9JyUWte/BdQc6E0+EwCSpvn3qZfNazFC4hDb83J/mHlf7Uu5hT4oYBmPPsshq LztovCmualC9aA+w6Sbm0HGLMg/wkw== =Dgxd -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/ZiZKdy_6k4bqDzbg%40mail-itl.
Re: [qubes-devel] Wrong formula in gui-configuration doc?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Apr 21, 2024 at 06:30:37PM -, qubist wrote: > Hi, > > Is the formula in https://www.qubes-os.org/doc/gui-configuration/ both > wrong and incomplete? > > The correct calculation (for 8-bit displays) seems to be: > > (3840 * 2160 + 1920 * 1080) * 4 / 1024 = 40500 > > If e.g. the 4K screen is 10-bit, this means 1.25 bytes, i.e. > > ((3840 * 2160) * 1.25 + ( 1920 * 1080 )) * 4 / 1024 = 48600 > > The doc does not address 10-bit displays. It doesn't matter what your display is using, the memory allocated in VM for the frame buffer is 32-bits per pixel. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYljLoACgkQ24/THMrX 1yyBjQf/dtV0qWxhSK0CXl+YSe5CxeZRygU8fyWikqHFfvd3z61Um7z7YFAMyJES SzW18+VzTZEVWqjvlnX5h34L4VZ2KenXr+4kuP33vRFS0B583cLvwEAvJ8f+3ddR P5Xc4IyvZTOJ/PL4RKeLOSM5SSCh8yayPOKWntGruhny1BccIkuCKnV/npVclfR5 tJVXoUCeV/ic+/L1rVo1Y7F4qHmLFmS7QQLoiyPT6pbWTQDJwdnChrRk+fAQr8QA KGcYMZ56Omtp8Qjox6WNzo0+gYBchXrLgJEuWwEiIP0hJEqxtkGWNRygkCh3qp6S miAnRC85zcHveqiJN24GbLX3qI8csA== =Htm+ -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/ZiWMuncw2fwM9xzE%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Apr 05, 2024 at 08:25:57PM -0400, Demi Marie Obenour wrote:
> 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 "+"?
I mean changing how dom0 makes calls.
> > > 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.
This also should IMO include the name as was sent to the qrexec agent.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQmAgACgkQ24/THMrX
1yw9fAf/TttfORQja9JZvDE0HELVhWDNKf3ZBRIZ8Q8DJJT9p9AM5/A/2Ifp20k7
csQ43n5YbN03b7Y7wkhJFgHpL3WYiGH94gg7hqr7L8U4jba7Q3Rn1C7KhMdT/iou
fRQCwmGHgh6UJiwPjlhnTU+Jdjv8PYhd4SmPcu7G/zlHOS1Ukim6W2XtfYe8efgP
zMOwGB3pjCaZMyZKWj+QTP56IBGzaHSwsBJcmF3Ng27Z84iu2I3+b6zPucm52Ab+
oPPiW3w9ABDDZ00Wqydhf+TF3zHUMRqxCM9oYdPFGZbcEqMAOvG9xvq2myvHGVQY
xL6rFzIlwnFDSkn6ZxwNZ6j4rFXBtA==
=fDP4
-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/ZhCYCDxD9o3-X5Zx%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
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.
> 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.
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
> 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.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYQiUIACgkQ24/THMrX
1yynWQf/QpvzpZ3kCiC1nMidobCjAY/rhtrramEpAuCpceEB7JxHj9vAfnJlify8
xag7PgRiIIZ31+eKxZrYfoW/QBOPiX9tU3/bhtUocjXqS6l0UDiSIA9UMDDqAl0w
UJainDUIdzRtH/EPXWjcr48FM3jZmKQPWOAmXteNZfWcmYWH6KtwEaHkyxZ2lLM0
zLcDnWrEykS8DbZpTbClxQ8S4vq8BcYKH1ULMAurmNE3sToJC858Sf4bp8QPvfLN
GU2ndsSMUsiHB/1mc7cazjD4DPTqpmy+Od98Cndd08JMpoLPZ6dqqwLh5C8hTQ/W
FcDghMPqLIutq4p35O2x2cqE13kOGQ==
=MM1I
-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/ZhCJQgWWtKihPusv%40mail-itl.
Re: [qubes-devel] Expected behavior of empty service arguments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYPEPUACgkQ24/THMrX 1ywpTgf/ShJpgfb+JaByYYeMur5PGNqaDqwvh79QrTjPTJCh0omrw0NvWcctcQGU o7YlEZ0eymAzF5iHDD2vG4MCwI0+xovaJrjV5LiOsauBCe5Jc1rRYTLS2aaK/Ysl b8gCUgst5VteLseGj7sNNu3LBPLTFljWc6pPg09c3sGB7wB1VH+dmPSfeV98tWX2 m3RrHP0jLUxDcmaJyEhcuDZUAOCO0g8/mVPaDe2qtBrvawpQFela0Cp/h9aP/+LH mgc+1n+fZC/Bg8u2AbJsadGd+bJ7MOt6Jrgcghn8rAO3Tkzc7OsZ+Nv7TBboYYe/ MQSJ/RoVT7/RCcdvl3kWK8KESov2Lw== =0j62 -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/Zg8Q9ZmEuvcscvEx%40mail-itl.
Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Mar 25, 2024 at 12:34:18PM -, qubist wrote: > On Mon, 25 Mar 2024 12:45:17 +0100 Marek Marczykowski-Górecki wrote: > > > IMO the main advantage of the single table approach is purely > > port-based rules (UDP or TCP), but the default firewall doesn't have > > many of them. They may be relevant for custom-input chain (but not > > always - sometimes you might want to use IP address in those too), > > and rarely for custom-forward. > > What do you mean? Using an IP address is possible in inet table too. Yes, but you need separate rules for IPv4 and IPv6 anyway, so the benefit of combined table is minimal. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBcogACgkQ24/THMrX 1ywrjAf/Uc7SvayVEarHjEKQ9bZDqCPp0+5bOYDFVhSgvLYzVjchku/teYehAtVJ Pe1LMrdeawIDUk2va3VCldS5zpjEoABDG68a2e4AR3QSFbw3pT4QlpH/0FiTOD1j aDjs2INgChAFi0hinw7oDt2H89IFc0ZQcFZhYhYR/3R8oZEJDoMAhazP4cAZnkI+ gaHCuptr0BP8nNVRsj6pjPLm779PD2821uF/jIKZIW+hTuG5xvmIQ9/d0XPvC6th APbkUUzFOeII+D0sHO7F6/SlrBxMV6iqdoUwOG7sWKGUTW5FdgA92/OOOl6vGj8C xllZmVSwKkMedB41HnMkS5eLHiB+IA== =LcEW -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/ZgFyiPSajbxi2wxL%40mail-itl.
Re: [qubes-devel] Why does Qubes firewall separate IPv4 and IPv6?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 23, 2024 at 07:55:17PM -, qubist wrote: > On Sat, 23 Mar 2024 13:05:39 + 'unman' via qubes-devel wrote: > > > However, the 4 and 6 rulesets are distinct and although they could be > > merged to a single table, the result would not be any cleaner. While > > there is some duplication, there are also distinctions. > > Sometimes keeping separate tables allows for greater clarity. > > I am not quite sure what you mean by cleaner and greater clarity. > Compare the 2 files I am attaching. > > separate.nft - as it is currently in Qubes > single.nft - a quick attempt to merge them into a single inet table > > separate - 133 lines > single - 82 lines > > I have not made any performance comparison but in regards to > simplicity, single.nft looks simpler to me. Perhaps it can be optimized > even more, e.g. dropping invalid packets in early in prerouting hook > instead of letting them to input. > > What do you think? Has any optimization been considered? A single table is surely shorter, but TBH I'm not sure if it's clearer. Some rules needs to be duplicated for v4 and v6, some don't. IMO the main advantage of the single table approach is purely port-based rules (UDP or TCP), but the default firewall doesn't have many of them. They may be relevant for custom-input chain (but not always - sometimes you might want to use IP address in those too), and rarely for custom-forward. In any case, changing it now is not an option. It would mean changing the API for custom rules, which was a huge pain for users migrating to R4.2, and we are not going to do that _again_ now. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmYBY80ACgkQ24/THMrX 1yzebgf/dkFXbsl7FYfgeqPEJTZ/HMPWieXum7vI06FpuLlHncPMhbJ833prtAvK CIZF/iEEOsngyiGT0VaH45NO3H4QBDftikwDQ3eB91+qJ792zcmaiuOj9LYStka4 XdsMhCbZsH8PeVfU36z7DGlZZ0lay1dAgqH4lVYu+LAA55mNFB6CqHLKq/APnrk9 Iopuz8m7AA8yEQ4lrAvYtFY3OpKQpKv0VZhDTtrILj0io7JdTzWNAbD0EFJmr7po YW3j+kuRCTEUK0c4wD00mU5ZAytEdjgZuKQSTnfbEbrzOxSOvY+6E5a4B+SnqA0D BciowS1par9BQDTZUsKnYPUIa0qySg== =CtoI -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/ZgFjzUYGEWwhdevV%40mail-itl.
Re: [qubes-devel] qubes-vmm-xen Patch Organization
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Mar 13, 2024 at 07:31:10PM +, 'Skyler Ferris' via qubes-devel wrote: > Hello, > > I am confused about a change made in yesterday's set of commits and I am > hoping you can help me understand. Among other changes, the patch formerly > known as 0500-xsa449.patch was renamed to > 0315-pci-fail-device-assignment-if-phantom-functions-cann.patch. The patch > declaration was also moved to the corresponding section in xen.spec.in (from > "Security Fixes" to "Backports"). This confuses me because I do not > understand the patch to be a backport (the [upstream XSA > advisory](https://xenbits.xen.org/xsa/advisory-449.html) lists 4.17 as the > target branch for this patch) and it is still a security fix regardless. But > I do not know why the patches are organized this way (eg, why it is useful to > list backports and security fixes in separate places to begin with) and > perhaps if I did the reason for this reorganization would be obvious. This is to help with updating the patches. The "security fixes" section is about individual patches, usually taken directly from the security advisories. At the point of adding them to the qubes-vmm-xen repository, they aren't in upstream git yet. The patches taken from stable-4.17 branch into "backports" are directly from upstream git repository - some of them are security relevant, but some are plain bug fixes. It doesn't make sense to split such bulk import into categories, especially since order of patches is important. When we update to a newer Xen version, patches needs to be checked if they are still applicable - keeping all patches that are taken from upstream git together makes the process much easier. You can see it in the commit that moves it: https://github.com/QubesOS/qubes-vmm-xen/pull/181/commits/f22008ff1f41a91213383b6ce532548bf2c26b4c - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXyFC0ACgkQ24/THMrX 1yzhbQf9HVMqU/Nb7OIYASapFSqVUb2b7nrz9qlO+oJ/jC4X7r4xp8zhgVV6z9Br cvKnrtlGpZlA6wPbPGO75JJ7qQillchXXoszD8i+rW/Ev8TolUZrQZBo7CQSsJr+ SIhA1jy3marucyQ8qMD5WmqV+xKteOgtec4zejCn4MmWAX7aS7W8Wb7QVjPv0NXL rvIrnGbKTmgBjlpAdL1qGWVxQZ83vytHXjnnhx+klx2hpkp0wUjnR4ScqVtTNoCz WFdmOkcVDrfPpMHrm6T7Uj/aOLTxdTI4/Jwe4BQ5EGhZT9spJT41OsdVJr1vfWrD ctQacxSBBS8pcUx15OxaMqz+e2yfaQ== =CR4j -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/ZfIULUh06ZK2NNaD%40mail-itl.
Re: [qubes-devel] Minimal minimal templates?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Mar 06, 2024 at 11:59:41AM +, 'unman' via qubes-devel wrote: > There's a recent issues on GitHub (#8980) about removing "non-essential" > packages from the Debian minimal template. > > The argument is that minimal templates should contain only "vital packages". > OP argues that a minimal system is one from which nothing can be removed > without breaking anything else, and therefore the minimal templates > should be trimmed accordingly. > > Debian has the concepts of minbase and base systems. > Minbase is a variant in debootstrap - it installs only essential > packages and apt. > The base system, or core installation, consists of essential packages, > and those tagged as required or important. > > The Debian minimal template is a core system, with some Qubes packages > installed. > In my view the minimal template contains a base system - it contains > packages that any user of Debian would expect to find installed. > > The docs say that "The minimal templates are lightweight versions of > their standard template counterparts. They have only the most vital > packages installed, including a minimal X and xterm installation." > > It may be that Qubes wants to ship a micro template, with only selected > packages installed, as well as the existing minimal templates. Or trim > down minimal templates to minbase, or smaller. > In either case, we would need to decide what packages should be included. > Any decision should be applied for all official templates. > > (I should say that building with minbase in debootstrap makes very > little difference once Qubes packages are installed, and that not all > packages correctly set out dependencies on packages that are assumed o > be present.) > > Thoughts would be appreciated. Generally, I think minimal template should be as minimal as possible, while still allowing reasonable easy customization. The latter especially means: - - working package manager (thanks to updates proxy, it doesn't require all kind of networking packages) - - some terminal emulator - - being able to target with salt (or ansible in the future) The last two are debatable. Terminal emulator may not be strictly required since there is qvm-console-dispvm. And also salt is rather arbitrary choice here, but IMO since minimal templates in practice must be customized to be useful, being friendly to automating this customization makes sense (BTW, this is currently broken in Fedora minimal templates). If there is some smaller base Debian variant to start from, IMHO it's worth a try. Currently the main difference is that minimal template skips installing "standard" task: https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/02_install_groups.sh#L45-L54 and also there is a smaller list of packages to be installed: https://github.com/QubesOS/qubes-builder-debian/blob/main/template_debian/packages_minimal.list many of the latter list probably can be removed. If some of those are actually required by other packages, it should be set in package dependencies. And if that's isn't the case, it's a bug to be fixed. Whether to actively remove packages that were installed automatically but aren't "vital" is another question. I suspect it might be quite fragile (something that wasn't essential before may become essential at some point, and thus removing will break stuff). I'd prefer the approach that prevents installing non-essential packages in the first place, so dependencies still can do their job. Minimal templates are built with "no-recommends" option[2] already. But maybe there is some place that doesn't use that properly and some "recommends" (not "depends") packages are installed anyway? [2] https://github.com/QubesOS/qubes-release-configs/blob/main/R4.2/qubes-os-r4.2-templates-itl.yml#L131 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXocJAACgkQ24/THMrX 1yzREAf+K3SnbpqCuQx8zyVyVZP1GqYpcvZ4yAn1+KMisiinpI1/x+3/wmOdP3f7 9AyuNBJ3wVBMgliYWAtQMLdZ2sqyS41KTEQd6BwVvuK9qjYp6cO72GdUdvK1WWbK 1cw6nq0gux+livKIbXjxgyjloABrGmzfG6F5/4QAi/Ce7TrED1DqlTW5RSjqORRj N8LWY0wZ+oyPn/fTNnNGh4KxZb5Ps+T8fHloK1E2A+N6mcBPkDaAsqvZ0+x2lqCR FxVgygFjoEo3LJBtjNamzg7ELjwWGDDXoKaYO0AfqIt93i04YNE3TtXh/YTH/QA+ 1omKuMoRjIj/0vJV+ACI/mnTYVyvfw== =tZfX -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/ZehwkPMa_2lkdnWv%40mail-itl.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 02, 2024 at 12:53:21PM -0500, Demi Marie Obenour wrote: > 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? The Xen's vPCI is mostly about arbitrating which access goes where (to the real device in case of passthorugh, to some emulator via ioreq protocol etc). It doesn't emulate all kind of devices that QEMU does, it only emulates enough to perform this arbitration. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjegoACgkQ24/THMrX 1yyV7Qf/VZzvpjJRhaVJTT5p2KEsbndG6+vPT8aNIl3sQgJgXX7yjJjD6+ZDwlK4 klIIAGWXP7ex0/sTw9fTO9bufafsPNpVb5QKkOk7LY6jPdD13XnFVa/3p+gpEwzU yb2HajTmDCGU2Irsv8luSp6ojf5BszVJYIvggoVa/Unq39w1VXPj038XotHEW9ud 6oEfUmYsZVSnKqxmVc63/BOQMtECotsQrCT1B81unBAgXflqoTsk/zSP8VIzrDBS F8MViA9BqjOEMhS4d1zSpwb/3VRGXwyKN/PM2rXNiOYNunViXZ8lJYzennJkcEbC OBVt6So9gE32voIIuOQGfg3/fgXu1g== =NWXw -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/ZeN6CkBRa2cR_ILi%40mail-itl.
Re: [qubes-devel] Status of Qubes builder v1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Mar 02, 2024 at 08:49:49AM +, 'unman' via qubes-devel wrote: > What is the status of builder v1? > Is it deprecated or obsolete? > Is builder v2 now the standard, recommended, (only?), way of building > Qubes and Qubes elements? > > numerous bugs and documentation issues rest on this. Building Qubes 4.1 is supported only via builder v1. Building Qubes 4.2 is supported by both builder v1 and v2 (official packages are built using v2). Future Qubes versions will be supported only via builder v2. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjIhMACgkQ24/THMrX 1yzxTQf/c9hEJy0mOYJ+YfoXpV3I7oO77OgwSeoCrWhk8skGxBbeZuyIdchhvOWw rLDa57Hr+UTmmtSb+N62E6ZEkSn3arvCCMingOIGYlvY0IYlGdXrr7XLN4MnMlbd i1Cn6febOghIqB6nXwrNQhx/PHTt7hJj6Eoq3pzs35mLwA4aqdMzQqMI/M+FFD42 NuX8EoGDMg8M/8xHpevDPQO2e8prtYXELPScBxR1D1KU7bEP2SVu7rd1IBvrqZcg /lgpvM7x4ed/9uOVP2bCJMrEyp8qvML769aBmQAEkhD7mmt7hJIkaZy4OC2wEQn5 jNN6D9B9a9GuawANyXTg7EdbLVVyvA== =oPD0 -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/ZeMiE8Q9vILgaQw_%40mail-itl.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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). 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? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjIYkACgkQ24/THMrX 1yzYSwf7BVnQnu7Nafdm0KE8S3f8dxNg/SEmAkmlr1P99Uic2ASOU/401ni9TTyc EoilwiGZNtlAL1SZQyzWYE6OOeSqEnG1a4FQP9cBs2VnzamTYKdYANG3F8WV0iV5 Xhn/dbcZMTkzeAvH5kv9FO/xq6D5WoVPKhZaF837lzMyQg49ZxdOTNydiR2n98WP I9no9mQZ3y1S5oYZdibClb8w5kZB4kBM1WSX3smw//3+oMbrxMB56oB2nYDzawgo BooSEuyCUyuxzq+qLg/bnCzixWVN5HNcVLedAWjv2i+xrQnjD1Q/vbhK4Ls2ajgO RWGZpSfWRXpdo/yjna7PYTmoNX0BgA== =EMoo -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/ZeMhid01SsUFnAr_%40mail-itl.
Re: [qubes-devel] Admin privileges of a GuiVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 21, 2024 at 11:41:54PM -0500, Demi Marie Obenour wrote: > 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? Currently several parts are missing (see above project), but the goal is to make it possible. I'd like to have enough integration to support two scenarios: 1. Full control by the user of GuiVM, including all kind of configuration changes. This doesn't add much security boundary between dom0 and GuiVM, but should still allow nice things: - much smaller dom0 (no desktop environment there), possibly base OS immutable with dm-verity - updates of desktop environment not tied to updating dom0 2. Limited user - any pre-made qube can be used normally, but user cannot make changes to any configuration. Possibly cannot also get shell in templates (only dedicated service to install updates, if not completely automatic). Configuration can be changed through dedicated management vm. There are a lot of options in between, mixed scenarios etc, but some may require extra features that are out of scope for now. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXXN/UACgkQ24/THMrX 1yz01Qf9HAIHlfzW5/21AbUl7zj413z30lwtzswlSYs21erB3OwhotTZdna4IR74 T3qzc3DWfWQdAep8z7kHwxgftXCZXE0b6heEojcQ7aGGbsTiIv2mx4ZVt87hlyQS 456og0xGTHHFNt0ln889v5Trx+HhAR6b9LH1tyUj0aLkdczU5H/YimlnTB0zzz0V PJ70dhBCz0YtMpzEXDdYdeGYIes2W1mmI2CeeDaCoiWtfWRP46wOFsFmDYsZywZi CGHdL3rObybiCC/LlVi8jobTr46SeXLoPxotriaJAZlsYF/RbES//r3PHEBvcYO5 cCWS5M6ur/Rad/WmTagdBsq+kcNssw== =TP+y -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/Zdc39RJKcJbBHuf3%40mail-itl.
Re: [qubes-devel] Admin privileges of a GuiVM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXWvoEACgkQ24/THMrX 1yzQJQgAhGLTcIqVZHyNgSFk/J4QmqbIQFhqOobMYiLuEnTbwXKRawtja8mMzZux fmAwpgGv7BQxGgCJaAsB1vx7oDlz8Vl3yYKLtJapeSfXrMSHrJEKx0Nmudq3YRD1 QN4VMUkVibVbbUwjbZrwaN+t8S2zCFYkxgky4u9n3a2x18NmD2yO7vOsaSFZVb/p 02kEN/8RQJfbsc2BCp+BiK5LNVIFrjZMZ2Gb/ASJAbiVkMEK/KrtEB5BnritQ+hM GkuUAiKod/CuJKu09nSmmeMXZN2jANVr9WMic/JR1AlMkOUNLvN6wggD5Iadd1Pm f+IF2ggy7tb2oVbTzlE/nq5BTxQ7mQ== =oX8Z -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/Zda-gQMVJG9S69nY%40mail-itl.
[qubes-devel] [qubes-announce] QSB-100: Incorrect handling of PCI devices with phantom functions (XSA-449)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Qubes Community, We have published [Qubes Security Bulletin 100: Incorrect handling of PCI devices with phantom functions (XSA-449)](https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt). The text of this QSB and its accompanying cryptographic signatures are reproduced below. For an explanation of this announcement and instructions for authenticating this QSB, please see the end of this announcement. ## Qubes Security Bulletin 100 ``` ---===[ Qubes Security Bulletin 100 ]===--- 2024-01-30 Incorrect handling of PCI devices with phantom functions (XSA-449) User action - Continue to update normally [1] in order to receive the security updates described in the "Patching" section below. No other user action is required in response to this QSB. Summary - On 2024-01-30, the Xen Project published XSA-449, "pci: phantom functions assigned to incorrect contexts" [3]: | PCI devices can make use of a functionality called phantom functions, | that when enabled allows the device to generate requests using the IDs | of functions that are otherwise unpopulated. This allows a device to | extend the number of outstanding requests. | | Such phantom functions need an IOMMU context setup, but failure to | setup the context is not fatal when the device is assigned. Not | failing device assignment when such failure happens can lead to the | primary device being assigned to a guest, while some of the phantom | functions are assigned to a different domain. Impact - --- The impact as described by the Xen Project: | Under certain circumstances a malicious guest assigned a PCI device | with phantom functions may be able to access memory from a previous | owner of the device. In Qubes OS this means a PCI device that should be assigned to some qube (like sys-net or sys-usb) may retain access to dom0 memory. When that happens, the qube to which that device is assigned can compromise the whole system. But, a malicious qube cannot itself cause this condition, as it happens before it is running. For such attack to be feasible, it needs to be combined with some other method to cause PCI device assignment to fail. Affected systems - - All Qubes OS versions are affected. Only systems on which at lest one passed-through PCI device has phantom functions are affected. Patching - - The following packages contain security updates that address the vulnerabilities described in this bulletin: For Qubes 4.1, in dom0: - Xen packages, version 4.14.6-6 For Qubes 4.2, in dom0: - Xen packages, version 4.17.3-2 These packages will migrate from the security-testing repository to the current (stable) repository over the next two weeks after being tested by the community. [2] Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents. [1] Dom0 must be restarted afterward in order for the updates to take effect. If you use Anti Evil Maid, you will need to reseal your secret passphrase to new PCR values, as PCR18+19 will change due to the new Xen binaries. Credits - See the original Xen Security Advisory. References - --- [1] https://www.qubes-os.org/doc/how-to-update/ [2] https://www.qubes-os.org/doc/testing/ [3] https://xenbits.xen.org/xsa/advisory-449.html - -- The Qubes Security Team https://www.qubes-os.org/security/ ``` **Source:** <https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt> ## [Marek Marczykowski-Górecki](https://www.qubes-os.org/team/#marek-marczykowski-górecki)'s PGP signature ``` - -BEGIN PGP SIGNATURE- iQIzBAABCAAdFiEELRdx/k12ftx2sIn61lWk8hgw4GoFAmW5Di0ACgkQ1lWk8hgw 4GphzQ//Ta+g8Y7Cjmx0w+byISlTHoxao0yhUcwHj11ssJfjVqf1P4TNTUuzQEae 0byIay9e2jo7y8nYKsvQ5gn7aSWHBtdw/ylwghMSuQ2iXRVKgI20Iuei1pA4H9Ct +Dz5faFtZq78JZIwT2P4BRNTeuLvlU7IsmH8F4uHz/yJFqb7Ji0iSrOJ3r7/SLAI zqHKDVGhzasVZOLgi91PcGHkvK33K8YIWCSzqWO7x6sw7+FX+9IgXciQ8gbGJcmc eazNizU5H5NQNTMBghSswXKHMgi9ldNhfN8UL5Mnxz8RgN0xGRVmN01tOftJFvig sBEfADIFtToEl8rh9n4AaQR+msK87sS1VYiC6k24FzzKizaFIW08jiQv9rzZST6u YxMUXd2q64mcGzRY2QdYx/Z+07Cp3h2crLCeJXclMuD2jawBL/br/nVfdHQfqf8R 8WZUOCrlV6ekuE1L+PgSkQpOozAg4j2EDQSPYoOcrnfSuGyI08AdDl+11B4Wj1Vb WsIOY8w+469DPt+Y2NdGH3thbtPlbJcwflRdTqq0SJ4d8IRtscOYTHsiE0+xPMgu QGAZaK7YJg1c1rB40/dbLirG1j9+WR+JVLLVASi8S012qYZ5zeal7ZT6rG+gr8mK H4Ninf3Tfhq4zA8bfjmxp10uI3VsYNOH3Tgv2MgmOcxsqdK6ZoA= =/jv7 - -END PGP SIGNATURE- ``` **Source:** <https://github.com/QubesOS/qubes-secpack/blob/main/QSBs/qsb-100-2024.txt.sig.marmarek> ## [Simon Gaiser (aka HW42)](https://www.qubes-os.org/team/#simon-gaiser-aka-hw42)'s PGP signature ``` - -BEGIN PGP SIGNATURE- iQIzBAABCgAdFiEE6hjn8EDEHdrv6aoPSsGN4REuFJAFAmW5Db4ACgkQSsGN4REu FJC+mg/+Kvsi4u0Xoem+j7DW+D2FDbFZfD/6k7vacUmOVZ27gKGZiVODdBc/+dUN 2fgxRme7RPMyxABSKs9SVx
Re: [qubes-devel] Is qrexec-policy-graph complete?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Oct 24, 2023 at 10:13:55AM +, Ben Grande wrote:
> There is no documentation on how to use it and it doesn't seem to accept
> any label/service that is not provided by default:
>
> Target can't be "@default":
This is intentional, because "@default" isn't real target - whatever it
gets resolved into is. I'll add explicit message about that.
qrexec-policy-graph should answer the question "where given call could
possibly be allowed" (and with --include-ask also including where it
with user prompt).
> ```
> $ qrexec-policy-graph --include-ask --source dev --target @default
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> }
> ```
>
> There are more services allowed, such as "qusal.GitInit" to "@default"
> targetting "sys-git" but it doesn't show:
But this is a bug.
> ```
> $ qrexec-policy-graph --include-ask --source dev --target sys-git
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> "dev" -> "sys-git" [label="qubes.OpenInVM" color=orange];
> "dev" -> "sys-git" [label="qubes.StartApp" color=orange];
> "dev" -> "sys-git" [label="qubes.ClipboardPaste" color=orange];
> "dev" -> "sys-git" [label="qubes.OpenURL" color=orange];
> "dev" -> "sys-git" [label="qubes.GetImageRGBA" color=orange];
> "dev" -> "sys-git" [label="qubes.Filecopy" color=orange];
> }
> ```
>
> It doesn't show any rule allowing "qusal.GitInit", but it does exist:
> ```
> $ qrexec-policy-graph --include-ask --source dev --service qusal.GitInit
> WARNING:root:warning: !compat-4.0 directive in file
> /etc/qubes/policy.d/35-compat.policy line 16 is transitional and will be
> deprecated
> digraph g {
> }
> ```
That I guess is the same as the above.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmU3yisACgkQ24/THMrX
1ywWCgf+OVQxFxfhUrqlCj57sLoap3KJynjKMM43uPsnNvFTV+IbVXGJr6etPhDl
Q/xw1swikyE2WdHThHKHKnQfeX/yB3sIs7fw57cDNnVeoyOMfdVVpgTVeLvXwHbO
mIz7RXaKCQG6gpkudEoCXrjggq7ffwzUj9R+njHgjspJtGSPIVJwuEB2xI07WgYk
J4BHGgA+lmHJTOzVFZy37Y7GurBbfNPpJlc0R73jwGH06b1t4UXYZ1s2dNIR8g/u
jdV+5i9vFUkSMueYysrhjnjskMIro0uOwgLfOLHXq9vAA86dJnEvldci6TCo1z9j
PhJFE8D7eTvl+KWOVjl1wAdjWXIGEg==
=GP/r
-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/ZTfKK2LhzR0RXtsG%40mail-itl.
Re: [qubes-devel] How to make dom0 qrexec call resolve @default token
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Oct 24, 2023 at 09:54:21AM +, Ben Grande wrote: > On 23-10-24 00:36:26, Marek Marczykowski-Górecki wrote: > > On Mon, Oct 23, 2023 at 09:24:13PM +, Ben Grande wrote: > > > Hello. > > > > > > Dom0 is not normally a client for extraneous qrexec calls, but in this > > > case, I need dom0 to resolve the domain name from the token @default via > > > policy. > > > > > > Policy: > > > > > > service * dom0 @default allow target=mydomain > > > > > > Call: > > > > > > qrexec-client -d @default -- 'DEFAULT:QUBESRPC service dom0' > > > > > > Dom0 does not requires the policy the call to be allowed, as it is always > > > allowed. Watching the qrexec policy logs, the call from Dom0 is not > > > logged. > > > > > > If I run from dom0: > > > > > > qrexec-policy 0 dom0 @default service 1 > > > > > > It resolves the domain but fails to run the command: > > > > > > INFO:policy:qrexec: service: dom0 -> @default: allowed to sys-git > > > 2023-10-23 21:19:28.154 qrexec-client[32893]: > > > qrexec-client.c:184:connect_unix_socket: connect: No such file or > > > directory > > > ERROR:policy:qrexec: service: dom0 -> @default: error while executing: > > > qrexec-client failed: ['/usr/lib/qubes/qrexec-client', '-d', 'mydomain', > > > '-c', '1,dom0,0', '-E', '--', 'DEFAULT:QUBESRPC service dom0'] > > > > > > If I run the command directly without the request id and the literal > > > domain name, it works: > > > > > > qrexec-client -d mydomain -- 'DEFAULT:QUBESRPC service dom0' > > > > > > How can I force dom0 to use the '@default' token? > > > As 'qrexec-client' does not allow tokens in the domain name yet, would > > > this be interesting to have? > > > > > > Documents read: > > > - https://www.qubes-os.org/doc/qrexec-internals/ > > > - https://www.qubes-os.org/doc/qrexec-internals/ > > > > > > I don't think there is one-step solution, but you can get policy > > resolved by using `qrexec-policy` in the 3-arg form (skipping domain id > > and process ident). Then, you'll get the result in key=value format, > > including resolved target= that you can use in a qvm-run (or > > qrexec-client) call. It even works with `ask` policy (you get the > > prompt), which means we finally can implement qvm-copy (not just > > qvm-copy-to-vm) in dom0 too :) > > > > -- > > Best Regards, > > Marek Marczykowski-Górecki > > Invisible Things Lab > > I'm on R4.1. Up-to-date. > > Can you please give an example of a working 3-arg form as it seems that > all positional arguments are required? Ah, right, 3-arg form is a R4.2 thing. This: [user@dom0 ~]$ qrexec-policy --help usage: qrexec-policy-exec -h usage: qrexec-policy-exec [--assume-yes-for-ask] [--just-evaluate] [--path PATH] SOURCE TARGET service+argument usage: qrexec-policy-exec [--assume-yes-for-ask] [--just-evaluate] [--path PATH] domain-id SOURCE TARGET service+argument process-ident To evaluate policy, pass 3 positional arguments: - Source domain name - Target domain name - Service name and argument separated by "+" To actually run a qrexec call, pass 5 positional arguments: - Source domain ID (Xen or similar, not Qubes ID) - Source domain name - Target domain name - Service name and argument separated by "+" - Qrexec process identifier (for data channel connection) Note that this usage is deprecated. positional arguments: args options: -h, --helpshow this help message and exit --assume-yes-for-ask Allow run of service without confirmation if policy say 'ask' --just-evaluate Do not run the service, only evaluate policy; retcode=0 means 'allow' --path PATH Use alternative policy path > Policy: > ``` > ## Do not modify this file, create a new policy with with a lower number in > the > ## file name instead. For example `30-user.policy`. > qusal.GitFetch * dom0 @default allow target=sys-git > qusal.GitPush * dom0 @default allow target=sys-git > qusal.GitInit * dom0 @default allow target=sys-git > qusal.GitFetch * @adminvm @default allow target=sys-git > qusal.GitPush * @adminvm @default allow target=sys-git > qusal.GitInit * @adminvm @default allow
Re: [qubes-devel] How to make dom0 qrexec call resolve @default token
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 23, 2023 at 09:24:13PM +, Ben Grande wrote: > Hello. > > Dom0 is not normally a client for extraneous qrexec calls, but in this > case, I need dom0 to resolve the domain name from the token @default via > policy. > > Policy: > > service * dom0 @default allow target=mydomain > > Call: > > qrexec-client -d @default -- 'DEFAULT:QUBESRPC service dom0' > > Dom0 does not requires the policy the call to be allowed, as it is always > allowed. Watching the qrexec policy logs, the call from Dom0 is not > logged. > > If I run from dom0: > > qrexec-policy 0 dom0 @default service 1 > > It resolves the domain but fails to run the command: > > INFO:policy:qrexec: service: dom0 -> @default: allowed to sys-git > 2023-10-23 21:19:28.154 qrexec-client[32893]: > qrexec-client.c:184:connect_unix_socket: connect: No such file or directory > ERROR:policy:qrexec: service: dom0 -> @default: error while executing: > qrexec-client failed: ['/usr/lib/qubes/qrexec-client', '-d', 'mydomain', > '-c', '1,dom0,0', '-E', '--', 'DEFAULT:QUBESRPC service dom0'] > > If I run the command directly without the request id and the literal domain > name, it works: > > qrexec-client -d mydomain -- 'DEFAULT:QUBESRPC service dom0' > > How can I force dom0 to use the '@default' token? > As 'qrexec-client' does not allow tokens in the domain name yet, would > this be interesting to have? > > Documents read: > - https://www.qubes-os.org/doc/qrexec-internals/ > - https://www.qubes-os.org/doc/qrexec-internals/ I don't think there is one-step solution, but you can get policy resolved by using `qrexec-policy` in the 3-arg form (skipping domain id and process ident). Then, you'll get the result in key=value format, including resolved target= that you can use in a qvm-run (or qrexec-client) call. It even works with `ask` policy (you get the prompt), which means we finally can implement qvm-copy (not just qvm-copy-to-vm) in dom0 too :) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmU29WoACgkQ24/THMrX 1ywsSAgAiLVRdMfihuve31orGwwKzLr158cfHVqVgiB93I4KulRJZJp5nWCMHn9N RzfcLGE8fVbIXMdgSS2zkrRnerNQaJMMHsXr7T+zj1KRkyV3BFKAn0LuALITkV8z W4ovnk2xtfuP2aDY13VoLCYllE8xPwbUBOUPLFQSMJiBLQVh0OfYNsbnyzITZ0W8 bbC20IGjMmvwj+HH91OyfhEphRZlDf8BpxCb1shpN7tdyBOelBiD4HyFP7BhJUZv 9lovughJRah6i0CDUfVI+eFVpsYM5owHCsa+OnUY5How4mu2H5rBYbEjbhxcY0gl 1E5RvgCuqCZp1W9o81mdJEGW7J2udQ== =QTs9 -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/ZTb1al5e6YHBtRR0%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Aug 26, 2023 at 06:40:32PM +0200, Marek Marczykowski-Górecki wrote: > On Fri, Aug 25, 2023 at 04:52:52PM +0200, Marek Marczykowski-Górecki wrote: > > On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > > > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > > > Status: > > > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > > > > > You can rename to plain qubes-policy-editor now. > > > > > > > > While at it, please add new files to packaging > > > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > > > now packages fail to build. > > > > > > > > > - Missing review of the last commit quoted above. > > > > > > > > The last commit looks fine. > > > > > > Added files to packaging. > > > > You missed files in python lib dir (qrexec/tools/qubes_policy_...) in > > the spec file. > > I see you added it, but as qrexec_policy_* instead of qubes_policy_*... And also pylint complains... See: https://gitlab.com/QubesOS/qubes-core-qrexec/-/pipelines/982836773 > > Generally, the preferred workflow is through github pull requests - we > > have CI configured there to catch issues like this. If you really hate > > github, sending patches like this is okay too, but since it requires a > > bit more manual work on my side (including pushing them to CI > > manually...), it also takes some more time to get them merged. > > > > > I believe in this case it is easier for you to pull from the 'lint' > > > branch instead of applying the patches manually as multiple commits were > > > done. If that is not the case, I will post the patches. > > > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint > > > > Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTqK34ACgkQ24/THMrX 1yxtPwf/Z52Kt409yhkedY7gkhdHR7xH11IHLMGPYlBTc/RWhcExNgP5PMDtSW/K Ab2P1MMZq3z4KbdkyDNjwNvuG70fQtlMLuyGi/2ITUiTFimQUUtE/1FUJD07X1+8 CPUUr0J27YiqkDs/zNCWH+TXFzj+tMi3AMEAdt3uEH9UbbS9d133CW9ao6deKxU9 TvTJPXgPrxaDPMHzmNGLwZZEy6SeRJ3tFW96WKU7eySN+5Qz4vlfcvjReT8BYgmS /ZzTkTTFZs+jRcQIemnUyCqTB9S2G0skrCXtPVmx/NLJ70r22d1Rwaxq+dN86lCI BnlgW66GfBZBBvfWeQl6eMimKES/wg== =YRF9 -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/ZOorforYf%2Bq4I4e8%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 25, 2023 at 04:52:52PM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > > Status: > > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > > > You can rename to plain qubes-policy-editor now. > > > > > > While at it, please add new files to packaging > > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > > now packages fail to build. > > > > > > > - Missing review of the last commit quoted above. > > > > > > The last commit looks fine. > > > > Added files to packaging. > > You missed files in python lib dir (qrexec/tools/qubes_policy_...) in > the spec file. I see you added it, but as qrexec_policy_* instead of qubes_policy_*... > Generally, the preferred workflow is through github pull requests - we > have CI configured there to catch issues like this. If you really hate > github, sending patches like this is okay too, but since it requires a > bit more manual work on my side (including pushing them to CI > manually...), it also takes some more time to get them merged. > > > I believe in this case it is easier for you to pull from the 'lint' > > branch instead of applying the patches manually as multiple commits were > > done. If that is not the case, I will post the patches. > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint > > Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTqKwAACgkQ24/THMrX 1yxnoAf/RLmMwlq+Fr66zwiwfo35U5twb6v+IQ5f5rtNGj1AR4b+iRB96qTTOMRc 3gfUBCHp9m54aVXnO0xIHoTaLnVSgYR99WOTLOZYiGEBN66/gWdWvehpTbuTeXO7 aZ/9vnRJc0rX8vwcvUS76XZzUJezP1r49d2V/7dZW/uheVW38FWOGqkwekEwgz85 HT+I7JLPcytz76RU9Jxo8o8oWMv08f/BnJjPqP2kfq5NXZcdM8zsj8ZNdTNGwmNt IWsY97NmWx3hH8mGEMtYWqBK/losDX2nEZE5lyGkU0cPdH4nr88QiyxVb7Z2Yqx+ hMB1G4GD337IItPPA4PLZIqK7HhmXQ== =PvDd -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/ZOorAEx3mpv02z67%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Aug 21, 2023 at 08:49:21PM +, Ben Grande wrote: > On 23-08-20 14:01:53, Marek Marczykowski-Górecki wrote: > > On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > > > Status: > > > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; > > > > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 > > > > You can rename to plain qubes-policy-editor now. > > > > While at it, please add new files to packaging > > (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right > > now packages fail to build. > > > > > - Missing review of the last commit quoted above. > > > > The last commit looks fine. > > Added files to packaging. You missed files in python lib dir (qrexec/tools/qubes_policy_...) in the spec file. Generally, the preferred workflow is through github pull requests - we have CI configured there to catch issues like this. If you really hate github, sending patches like this is okay too, but since it requires a bit more manual work on my side (including pushing them to CI manually...), it also takes some more time to get them merged. > I believe in this case it is easier for you to pull from the 'lint' > branch instead of applying the patches manually as multiple commits were > done. If that is not the case, I will post the patches. > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/src/branch/lint Yes, that's fine (but see above). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEyBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTowEAACgkQ24/THMrX 1yyQowf47CY7VTxIizI1fk8v5c58RIltQ9YFF7eRbhB87TaiH3GEhbQQfoWmv41k 4rvbWWP9QuN7tVoTCAfadB10BH0cI5H5AmdvhFzF1iMwlaEv7726pnX6k+qbhAM0 Nlvh9KbfczjxPspjq80ETc38pHX2lO6x6G7jlYubNl7E96mPhJwCxK5QD0EETvMo lfyIXIGX0uMHBry+SinhAY4WGGWoTKB+BA6/iJrfiooCJHKcJNVkI3HjpmnvpM3l 35ZRzBLCYYqQi4CqSkPwDhXGgWkTxdp/b0JzVyeyvcjkhAVXcD8ba9t0JRm68QAd T+69fv45P9OHvu5ZtywYEhPssSFP =5ea7 -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/ZOjAQDbDKSxAuAjs%40mail-itl.
Re: [qubes-devel] Re: qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 11, 2023 at 02:17:00PM +, Ben Grande wrote: > On 23-06-01 19:03:31, Ben Grande wrote: > > The editor does not require the policy(.include).List RPC as of the last > > commit[0], only requiring policy(.include).Get and > > policy(.include).Replace. > > > > The downside is that when the file is not found, it guesses the file > > path using POLICYPATH and INCLUDEPATH, when running from and AdminVM, > > the qubes-core-qrexec package needs to be the same on Dom0 and AdminVM. > > > > Can this cause problems? Should it be reverted? I matching the > > 'wanted_path' via regex a better alternative? > > > > https://codeberg.org/ben.grande.b/qubes-core-qrexec/commit/445e7db143b5894a8c75394bd2a0bd5a7a8b759e > > > > -- > > Benjamin Grande > > Reminding of code contribution. Sorry for late review. > Status: > - Missing change 'qubes-policy-editor' to 'qubes-policy-editor-gui'; https://github.com/QubesOS/qubes-desktop-linux-manager/pull/172 You can rename to plain qubes-policy-editor now. While at it, please add new files to packaging (debian/qubes-core-qrexec.install, rpm_spec/qubes-qrexec.spec.in). Right now packages fail to build. > - Missing review of the last commit quoted above. The last commit looks fine. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTiALEACgkQ24/THMrX 1yyDEAgAiBOCrsIrQ3+AbSY86BDVRpUs+SI7flX+h/9oCcVR/p1bLhzlleBawIGW nDhHwYs8kfShPUFoYB6ZNo8UCW+IOy5aWs+MJ8JMmC9CpekBhMMbR5Hambs4RX93 jUmahuK3AqQgj1NDOjRxxdx2/uurHLb/ij/ftiRNgtL9wwIQMLZlRa3xnfBmDISK 2CDfGu3xgYZ2AZYw8uCeHuUDXQfnCyHulvDmgLP3nAT+3vi2i+LxmDsip8YOgq6b KE2qQ1BwYH8skH03r6iswqbv0A1DoH6KNi9YrzXywjtfmczqvsSP6tME7hksgxnd Fad1DOxZwn8uhIRowIsTROtPx5EhTw== =P2rL -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/ZOIAsQhJpDN%2B28Am%40mail-itl.
Re: [qubes-devel] Re: [PATCH] parser: Change warning of invalid path to error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 11, 2023 at 02:13:56PM +, Ben Grande wrote:
> On 23-05-26 16:59:07, Ben Grande wrote:
> > Signed-off-by: Ben Grande
> > ---
> > qrexec/policy/parser.py | 11 +--
> > 1 file changed, 5 insertions(+), 6 deletions(-)
> >
> > diff --git a/qrexec/policy/parser.py b/qrexec/policy/parser.py
> > index ab50f9e..143f77f 100644
> > --- a/qrexec/policy/parser.py
> > +++ b/qrexec/policy/parser.py
> > @@ -1956,15 +1956,14 @@ class ToposortMixIn:
> > if "/" in key and (
> > not key.startswith("include/") or key.count("/") > 1
> > ):
> > -# TODO make this an error, since we shouldn't accept this
> > anyway
> > -logging.warning(
> > -"ignoring path %r included in %s on line %d; "
> > -"expect problems with import order",
> > -included_path,
> > +raise PolicySyntaxError(
> > filepath,
> > lineno,
> > +"invalid path {}, only paths inside the directories {} and
> > "
> > +"{}/include are considered".format(
> > +included_path, POLICYPATH, POLICYPATH
> > +),
> > )
> > -return
> >
> > self.included_paths[key].add(included_path)
> >
> > --
> > Benjamin Grande
>
> Reminding of unreviewed patch.
Pylint complained about duplicated POLICYPATH, so I adjusted it to use
named arguments. Otherwise, applied, thanks!
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTh//8ACgkQ24/THMrX
1yz4PQf+JidHMMTgRgpSF6hzNoQG6J9QUxmKsdAil1ZpbGlwkS7OCRxAupBsDkwc
5rYX52bPzq4UWnK1Bq8urHB0EyxaAt8y2XVtMbaTS4UMpHTEzRj34g0jrsRUkRHl
tmpAQsDbloqRA6N6IzyYOo7J8E8LldyyiueesuFBi7H/fGJZq74MQ9M1nZdC/ibn
mgHT4OsbuI2i1xapZ6sxxUFsywJHf9ojUFq7Yn+MJFcFhrB0wZ+x2fdRg5XdoJuP
UJOlRGytrznDTxvvCVermyAOo/RHAF2tIUQPkHKEak5wgywbYzPv/QTO0voO/784
ZVdvuAbJ4cjYPAfzkae2q1KZDY0hXw==
=6ED7
-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/ZOH//g2z3Sl5tZwV%40mail-itl.
Re: [qubes-devel] Re: [PATCH v3] Fix policy.Replace changing mode and owners
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, Aug 11, 2023 at 02:12:25PM +, Ben Grande wrote:
> On 23-05-28 22:35:31, Ben Grande wrote:
> > Enforce file mode and ownership for replaced files.
> >
> > Signed-off-by: Ben Grande
> > ---
> > qrexec/policy/admin.py | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py
> > index da5bd9f..d575a6e 100644
> > --- a/qrexec/policy/admin.py
> > +++ b/qrexec/policy/admin.py
> > @@ -19,6 +19,8 @@
> >
> > from typing import Optional
> > from pathlib import Path
> > +from pwd import getpwnam
> > +from grp import getgrnam
> > import contextlib
> > import fcntl
> > import os
> > @@ -201,6 +203,13 @@ class PolicyAdmin:
> >
> > temp_path = path.with_name(RENAME_PREFIX + path.name)
> > temp_path.write_bytes(data)
> > +temp_path.chmod(0o664)
> > +uid = getpwnam("root").pw_uid
> > +gid = getgrnam("qubes").gr_gid
> > +try:
> > +os.chown(temp_path, uid, gid)
> > +except PermissionError:
> > +pass
> > temp_path.rename(path)
> >
> > # Remove
> > --
> > Benjamin Grande
> >
>
> Reminding of unreviewed patch.
Thanks, applied.
I also changed it to handle missing 'qubes' group, because that doesn't
exist in CI.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTh/+oACgkQ24/THMrX
1yzYIQf/Tg2vIz3J6CvqEd3mfqrf5KfEI3l+bC/NQOJxcg+09anC+VeTN/gA1hVw
kmmTBHdfTXJCq6f4KOMHRfNMPRdtarFCdz6UOIfqkHfWlmY8LAokRc/+BqCiJxgQ
/lR2y2Pv2/zNHys67p6k4ZN1Xqxp/dI0NjsnJH55NTeME4EFVPu8d3ZW7OPHqKfm
Ex8m9QYzzIJmrxDTgjKmogv7mMiEz1T0awjzwwDJrnprgnfKvT3LuIj6WIm0e8QO
VC9a4o6sCoxTMWLIasmvQTjWT45Vpi04F0MFlRGJJAa0MumccLkFm7qQvOouP2bu
R60o4/tlfE/qwvYed8JXbdwGf3rZew==
=zZwV
-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/ZOH/6hzpBDuXBOeu%40mail-itl.
Re: [qubes-devel] Changing the way we use milestones in the issue tracker
ven had time to > > diagnose. With the new approach, you can be confident that the Qubes devs > > have not only looked at and considered each issue in a given milestones; > > they've actually decided that action will be taken on that issue and plan > > for it to be done for that release! (Of course, the Qubes devs reserve the > > right to modify or remove milestones at any point at their discretion. > > Assigning an issue to a milestone isn't a binding commitment of any kind, > > and the realities of the software development process guarantee that > > milestone assignments will often change.) > > > > A side benefit of this new system is that it makes it clearer that every > > issue opened is merely "under consideration" until the Qubes developers > > approve of it and decide to act on it. (Even under the old system, > > assigning a bug report to the "Release 4.1. updates" milestone, for > > example, doesn't mean the Qubes developers plan to act on it or even that > > they agree that it's really a bug in 4.1.) > > > > Since we will no longer be using milestones to represent which release(s) a > > bug affects, we'll instead use labels like "affects-4.1" and "affects-4.2." > > This will allow us to accurately track cases in which a bug affects > > multiple releases. (I expect that "affects-*" labels will be used mostly > > with bug reports, but there are probably some cases in which they can > > sensibly apply to tasks and enhancements.) > > > > We currently have a milestone called "Non-release," which is for issues > > that are independent of the Qubes OS release cycle, such as website, > > documentation, and project management issues. This milestone provides > > little value and will be phased out. The main reason it existed under the > > old system is to satisfy the "every issue must be assigned to a milestone" > > rule, but it's actually redundant with labels like "C: doc." > > > > Similarly, we currently have the "Release TBD" milestone, which is for > > enhancements and tasks that will (or would) be specific to a Qubes OS > > release but have yet to be assigned to a specific release milestone. This > > milestone makes no sense under the new system, as *every* issue is in this > > state by default until it is hand-selected for inclusion in a specific > > release milestone. > > > > Finally, we have milestones like "Release 4.1 updates" (as opposed to just > > "Release 4.1"). Under the old system, these "* updates" milestones were > > used to collect issues (mostly bug reports) that were filed after the > > corresponding stable version was released (in this case, 4.1). In other > > words, all 4.1 bugs reported during the testing stages were assigned to > > "Release 4.1," then the stable 4.1 release was announced, the "Release 4.1" > > milestone was closed, and the "Release 4.1 updates" milestone was opened in > > its place. (In practice, it was already open by this point.) All "Release > > 4.1" bug reports that were still open and all subsequent 4.1 bug reports > > from that point onward were assigned to this "Release 4.1 updates" > > milestone instead. (In some cases, some bugs that the devs knew they > > wouldn't fix in time for the 4.1 release might've been assigned to "Release > > 4.1 updates" early.) Not only is this process confusing to newcomers > > (because the distinction between "Release 4.1" and "Release 4.1 updates" is > > too subtle); it also renders the progress indicator on the "Release 4.1 > > updates" milestone fairly meaningless, as it is attempting to track > > progress on updating a version that has already been released, which is a > > never-ending process until that release reaches EOL. These "* updates" > > milestones are also being phased out. > > > > Thanks for reading! To view the latest milestone guidelines at any given > > time, please see: https://www.qubes-os.org/doc/issue-tracking/#milestones > > > > -- > > 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/6987bd94-817c-f216-e923-0d3029723f43%40qubes-os.org. > > > > -- > 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/NbPVjTN--3-9%40tutanota.com. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmTTnwUACgkQ24/THMrX 1yzpSwf+OvC4uOCQjLKsOZyzAVPGpoDkzizF0NScXodGysRxfjnrUlK4DbLGZ/Uz lHfCZjshDP19YjTaGBMtFx0+5LZVtUsn/LufbpSTQAFZ3eInnyI3ggIuuSW5Ru1m 4n29/t147A+RmMQn2TL4z8hP7DDSyYGdxqLIE26/IvukWrfvAlBQPlMIov1FRf4D lHloo7LmNQFa19flf6yoCluRPrP1OLjQyh71+KsGnWlR1f+eZ4tLBiINrv3Sb9zd mcqBgsEkTtFtATbLYDSP7zJMkef5WrLOcZkoeMpwk2YBTwpPW+EC3wYzm635wcby hc3ZGqBAVv4CPG5HTs+8dfy03DOj0A== =gHO0 -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/ZNOfBTfiAXP0oONo%40mail-itl.
Re: [qubes-devel] [PATCH] Fix qubes-input-sender-mouse@.service failing on boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 30, 2023 at 01:41:10AM +, 8h45 via qubes-devel wrote: > If sys-usb boots up before the user has logged in, > qubes-input-sender-mouse@.service fails permanently. This patch makes the > service restart on failure at a reasonable time interval. If the policy is set to "allow", it should work even before log in. But with policy "ask", indeed it will fail. But then, there is a post-login script to restart those services one time. It's called via /etc/xdg/autostart/qubes-input-trigger.desktop in sys-usb (/etc/xdg/autostart is processed when starting user's graphical session, so - just after log-in). If for some reason it doesn't work for you, the issue is there. > diff --git a/qubes-rpc/qubes-input-sender-mouse@.service > b/qubes-rpc/qubes-input-sender-mouse@.service > index 309f60f..18fbb72 100644 > --- a/qubes-rpc/qubes-input-sender-mouse@.service > +++ b/qubes-rpc/qubes-input-sender-mouse@.service > @@ -6,3 +6,5 @@ After=qubes-qrexec-agent.service > Environment=TARGET_DOMAIN=dom0 > EnvironmentFile=-/etc/qubes/input-proxy-target > ExecStart=/usr/bin/qubes-input-sender qubes.InputMouse /dev/input/%i > "$TARGET_DOMAIN" > +Restart=always > +RestartSec=1 Restarting the failed service indefinitely, every 1s is a bad idea. The common case of a failure is (intentional) policy deny, and restarting every 1s will both waste resources and spam the user with notifications about the refusal. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmSoHKoACgkQ24/THMrX 1yx2oggAiuA6Pfwqoavx8pgEO2W8xuZZLBi9saBTTifrGEoQgB0FeuhL+NMBZaYS wcPB2k0Ru8E/QTvZxcm7Ug+0F/s23j46Pr02iKDykIMAuKxaYleuhYjpOrvjCH5c QWgnlEiN9PfFzYFb8k9JCitwnuB5umYct6e5/NZeXQx4ooewXcQNjbUz63lbmiCk 00dK3ru0xuexl4lgYnIDwjpqNLel0SmkMlsITPIh6gOJ7/7MmkroSx2XUbpO/8a1 7JVoOkTNAV9+0JM/AVHtXtEXVT9hoqrhNEehSYK5VqNcWVNozQQX2rJT0U+XJswO vdzeEhF6PiAPLiRbYEpMUgjI3hP+hw== =20O+ -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/ZKgcqiB/wq5aHqOq%40mail-itl.
Re: [qubes-devel] [PATCH v2] Fix policy.Replace changing mode and owners mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, May 28, 2023 at 09:41:37AM +, Ben Grande wrote:
> Enforce file mode and ownership for replaced files.
>
> Signed-off-by: Ben Grande
> ---
> qrexec/policy/admin.py | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py
> index da5bd9f..5f80070 100644
> --- a/qrexec/policy/admin.py
> +++ b/qrexec/policy/admin.py
> @@ -19,6 +19,8 @@
>
> from typing import Optional
> from pathlib import Path
> +from pwd import getpwnam
> +from grp import getgrnam
> import contextlib
> import fcntl
> import os
> @@ -201,6 +203,10 @@ class PolicyAdmin:
>
> temp_path = path.with_name(RENAME_PREFIX + path.name)
> temp_path.write_bytes(data)
> +temp_path.chmod(0o664)
> +uid = getpwnam("root").pw_uid
> +gid = getgrnam("qubes").gr_gid
> +os.chown(temp_path, uid, gid)
Just in case, I'd wrap it in try/except to not fail the whole operation
if chown fails (if the thing is running as non-root user for example).
> temp_path.rename(path)
>
> # Remove
> --
> Benjamin Grande
>
> --
> 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/ZHMh0fQxcKHG70gP%40personal-mutt.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRzWZEACgkQ24/THMrX
1yxnvAf+NJ5PSy0IKlHduJiMSsuGSmE1QarvNp6hOMZqxGgqjRg9pKwS2tF69StW
1zOM5xNmls888CKkxKeS7SsSOAMAlRt8gf1+mhS3SGGPYrDiZZcuvzClBw+JOmn7
moAbokIL5qBtTZ57X4eBC5e7iOisA1n1VIqCqwLxnQOsb2aP5BoItcpIKfilIh+I
5RI3rs/58fQfKVsLfb5IsLqolGh4PX3OKqDq8rCwABPmMYfyqfGAJ5ywiiV01LRf
lgsKVJHM1mQuSYUaazEmOVFLWvc73CeSbk+Blz08cYuogxnMK25iMSW78mPm5DiL
xo4w3oq4DvvjPW6wJcgOAN987AulDQ==
=utmA
-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/ZHNZkbdivHwyTZG2%40mail-itl.
Re: [qubes-devel] Re: [PATCH] Fix policy.Replace changing the file mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, May 27, 2023 at 07:33:53PM +, Ben Grande wrote: > On 23-05-27 19:25:54, Ben Grande wrote: > > Without this, it defaults to what unmask allows, normally 644. > > Without being group owned, editing the policy manually leads to a RO > > file and if the user force writes, will change the ownership to > > user:user. > > > > Signed-off-by: Ben Grande > > --- > > qrexec/policy/admin.py | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/qrexec/policy/admin.py b/qrexec/policy/admin.py > > index da5bd9f..c5bfc23 100644 > > --- a/qrexec/policy/admin.py > > +++ b/qrexec/policy/admin.py > > @@ -201,6 +201,7 @@ class PolicyAdmin: > > > > temp_path = path.with_name(RENAME_PREFIX + path.name) > > temp_path.write_bytes(data) > > +temp_path.chmod(0o664) > > temp_path.rename(path) > > > > # Remove > > -- > > Benjamin Grande > > Perhaps it should also set the ownership to root:qubes? Yes, I think so. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRya6sACgkQ24/THMrX 1ywTKAgAhiA0mnNSdHQNdcC07kujGCQAoliWmA4xLZ62eC/puXoeMPfIpAQDbDrJ nH9V9Ep2OaERUBRO0+/gcmnGWxRmeMYD1WGt/NlGlrCXRhpJjxxBZx5xSeIZRt6b DAtrVADJr650spRO/WuxmyStaPnZkXvefcz89Wl4qJUscrmNNnGGC1E1zmbh1V49 onJJNMemDalFyTPkA0uajh7CeSwEdpml4G+tBVh8T11k0F6DBVT0BdlsZyFrEHF6 KjB5Vlv2xVog13z7KNvWxfYn2s/Om4sTJMqCCCQr0vexpG0RXZBAEgMdI/xf5und Y3/0vyvY2vmrnE+UkuLUzDM0Yk32fQ== =dHmf -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/ZHJrq0I4yBA1cXy6%40mail-itl.
Re: [qubes-devel] qrexec parser - !include-dir allows multiple params
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, May 26, 2023 at 03:48:18PM +, Ben Grande wrote: > Issue report. > > Fails: > !include a b > Works: > !include-dir a b > > I believe that !include-dir should also throw an exception on invalid > number of params, but it currently doesn't. I did not understand why > !include can raise the exception and !include-dir, that has the same > code, doesn't. I can't confirm it, for me both fail. Which qrexec package versions do you have? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRw1wQACgkQ24/THMrX 1yxIeAf/Yc3wYavWlq6a+4CbPfWWXsXTdP6L2dqKMYga+Dpj2V21/NN7/5csYbxT h3DzojeSgO/I2Q3ltvcY3jA724dsd9WhXwfvH/bPXqulnZ6vROslVZhUBENGmo/x ZY2xTK+nTAhBOBxXyucNYPEaN/9NXVFEBssBNblEPmO4ep9Qgbvr1N2YMTJURQrZ Uj82wwJHud3HtoJpx6Xk96d3P7XKjz4PwFw8XVqeyCjk2WGPSGIDZtK3InKWpxJV kgAT12HHaq6TcDZXUS7s+ZFIzojUZhjBnG3PCgJnx+VbLlLbtkmhKieZG1BjQQsn xxdUSRbYpUItzxcFqSergC3Auql37w== =NpuG -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/ZHDXBA2xtK63nJab%40mail-itl.
Re: [qubes-devel] [PATCH] Fix python3-qrexec missing on qubes-core-qrexec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, May 26, 2023 at 08:58:58AM +, Ben Grande wrote: > > -- > Benjamin Grande > > -- > 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/ZHB00gq0Ir/XWDqB%40personal-mutt. > From 84232c53e665eb012c87d44b481157c863aaf4e9 Mon Sep 17 00:00:00 2001 > From: Ben Grande > Date: Fri, 26 May 2023 08:54:46 + > Subject: [PATCH] Fix python3-qrexec missing on qubes-core-qrexec > > Signed-off-by: Ben Grande Thanks, applied. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRwn8sACgkQ24/THMrX 1yzrAgf9FzbnyeFYLw8mLEZ8KbDK185uFX3iz0Gag5SXnxq/uvy94iJw2PuH67bQ paq9rAGoXNXkPO3o9wha8aE5BKN10s4KZVRfWnY930zfzEsQKsXtOdsblOS/VIW4 v73lf/wf/+ZsOxE27TcvsiQrf4Mca5losARTtEDySGshMT/IaaRkTonRHcO9qORw NesWjcP3iNZp+aoqwu2vS70h2Hg16bFDg+7fnyE1ub65nad4BB5WCvzcSi1bwHid hiIFujbDTSYzmXi0WHAMlDeb4Kjm1w0ZCeD2yZkbNW9j1nlJbxMFHKTbwvQaho7B FvuouCOALq8ucSxEwNxQfKLWf3HCBw== =BHOc -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/ZHCfyhWBbMn2a4nC%40mail-itl.
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 25, 2023 at 11:24:15PM +, Ben Grande wrote: > On 23-05-26 00:57:04, Marek Marczykowski-Górecki wrote: > > On Thu, May 25, 2023 at 10:18:43PM +, Ben Grande wrote: > > > On 23-05-25 11:45:45, Demi Marie Obenour wrote: > > > > On Thu, May 25, 2023 at 10:54:48AM +, Ben Grande wrote: > > > > > If the parser can be packaged to DomUs, that would make linting > > > > > policies > > > > > from any qube possible. These are the dependencies I mapped: > > > > > > > > > > qrexec > > > > > __init__ > > > > > exc > > > > > utils > > > > > policy.parser > > > > > > > > > > See the imports at: > > > > > https://codeberg.org/ben.grande.b/qubes-tools/src/branch/main/qubes-policy-lint > > > > > > > > That should definitely be doable. > > > > That should already be the case, qubes-core-qrexec should be installed > > in domU too. > > Hum, on Fedora yes, on Debian, incomplete. > > Fedora - expect qrexec denied: > $ qubes-policy > Request refused > Command Failed > > Debian - unexpected module not found: > $ qubes-policy > Traceback (most recent call last): > File "/usr/bin/qubes-policy", line 2, in > from qrexec.tools.qubes_policy import main > ModuleNotFoundError: No module named 'qrexec' Ah, that looks like a missing dependency on python3-qrexec. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRv85gACgkQ24/THMrX 1yyligf9E9Y+fyLF7fmjT9q4e8qS00KYRDB9W5ocrwUvW5+hUCBZlBMlMb6g1uPX Tl+jvwIegV1ivTXt6qJk3Su4RGot/SlTJ1r/i+u0sokS4I+NGJ+2qWV1jxQEHDnb sou/p2156+ufo0dkAB2XOm3tR5QQSQ1ODMdtZsVnsrFtE9LYxAMje4aSWBab0LEs YIT8Ila5VQ9miRgJfcTjdcPXPkVBXEPsE0KwdoB1Fra/skwFR7zSPFmnVVVoh3e9 W+HR0umTm1YRSQ+mwyxajeoCWRwgywDXiUqOBun6Eg2EJM60EJc3wck3Ynd8Idrf 9NsgsJA0EJEJ/FNOl3PRO9fPTYzVxw== =bJVk -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/ZG/zmPw1sfbmeRkH%40mail-itl.
Re: [qubes-devel] vim-qrexec - A Qrexec companion for the policy breakers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 25, 2023 at 10:18:43PM +, Ben Grande wrote: > On 23-05-25 11:45:45, Demi Marie Obenour wrote: > > On Thu, May 25, 2023 at 10:54:48AM +, Ben Grande wrote: > > > If the parser can be packaged to DomUs, that would make linting policies > > > from any qube possible. These are the dependencies I mapped: > > > > > > qrexec > > > __init__ > > > exc > > > utils > > > policy.parser > > > > > > See the imports at: > > > https://codeberg.org/ben.grande.b/qubes-tools/src/branch/main/qubes-policy-lint > > > > That should definitely be doable. That should already be the case, qubes-core-qrexec should be installed in domU too. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRv58AACgkQ24/THMrX 1yyxeQf+JB0k8IskH/pyS0GokVsnyW2K3RCOUpdGdlwS6IZ0ok7/q4VeuEB0RGzm lavVrrkow7NguTBKSppKxxPEMq8GyNw4VdWP60R5QFP5+j/QzYk+vSAsv+mwAmmt RT39UjzqJYEa3WNBUpZFMmlO/TP6IXdwhzwobU7RlX2z/Y/uIQQn0eeyIR0+g+5C jRLuWuTw0cSKgm5N7Qd9dCEhhtvbBdTbQCnTZVJb1aW+jQDevR7VmGJOK026OsOI 79xn+s0sL/tr34XTzfuh2xszVVXD7t04ToE+y10oZDfv/LQ9+vVhQ9i8jzkiaxGd vXI6Q5DGkIP+H+bzrJJPDKFqrDNbxA== =gn2o -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/ZG/nwA852xbb7BXd%40mail-itl.
Re: [qubes-devel] qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, May 24, 2023 at 10:29:07AM +, Ben Grande wrote: > On 23-05-19 14:52:57, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Those look very useful! > > > > I have one comment to qubes-policy-edit-terminal: when using > > policy_get() (or policy_include_get()), you get a policy content and a > > token. Use that token in policy_replace() call to detect race conditions > > (when something else changes the same policy file in the meantime). > > Will add the token argument and let the exceptions handle the rest. > > Just one thing, the name "qubes-policy-editor-terminal" is non-ideal. I > just added "terminal" to the name because "qubes-policy-editor" was > taken by the GUI application implemented with: > https://github.com/QubesOS/qubes-desktop-linux-manager/pull/143 > > Can Qubes keep the standard of using "*-gui" for GUI applications? > Some use, some doesn't. In short, I am asking for the Qubes Team to > rename the current GUI app to qubes-policy-editor-gui, so the one > provided by this thread can be named qubes-policy-editor. Marta, what do you think? I think we can do that. > If the answer is no to the rename action, I will just add the token > argument. > > > > I am doing vim-qrexec, will notice when ready for review, it requires > > > the qubes-policy-lint for linting the policies from within Vim. So I > > > will wait for a resolution of this topic. > > > > > > Repository: https://codeberg.org/ben.grande.b/qubes-tools > > > > Would you like to submit those to the core-qrexec repository? > > Yes. Also take a look vim-qrexec to see if it is possible to be included > in qubes-core-qrexec: https://codeberg.org/ben.grande.b/vim-qrexec > > It is not complicated, but it is extensive and written in VimScript. > It can be used in DomUs and Dom0, but the lint tool can only be run in > Dom0. If you prefer, I can start another thread to better explain it. That would IMO makes sense. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRt6H0ACgkQ24/THMrX 1ywh9Qf+KkqZO75sI69MaVhfTif82bl0hcJy+S/sTYm5DXOmthDICQ3Af/KYmaQT ATyZXzE3eJt6zvUmL/v7t+b24KRqh43/AWrHAxjZOvzCFlq08QavKrna2Yaz4w5I X3tR1RO07R/aCH8XRi+erxDMslXz8jKUVWKF2LIvcPPzGnj/zJW5oQOF/sbra7Kf WyDWOxxHkW3/2afVIWgU0nLssiT1cQfJd6NfofBc0Gx+5ZpPgc5BNyo9OtR2zRAp 3qhS8A/elFriuF8QzoPI+HAAvrO4fTPgPvGLSmNAjOOyo75BtFrhyW7dSV6R4OSn GxVE9hnMZuvkSn1PEhuO88BHOd+LqQ== =0Zd3 -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/ZG3ofcu%2BMDEeoo27%40mail-itl.
Re: [qubes-devel] qubes-policy-lint and qubes-policy-editor-terminal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On Thu, May 18, 2023 at 06:20:06PM +, Ben Grande wrote: > I created a standalone lint tool for the Qrexec policies, the name is > qubes-policy-lint. It is a wrapper around qrexec.policy.parser > TestPolicy|StringPolicy. > > You can lint normal policies: > qubes-policy-lint /etc/qubes/policy.d/*.policy > Or policies included by !include-service: > qubes-policy-lint /etc/qubes/policy.d/include/* > > There is also qubes-policy-edit-terminal, an alternative to > qubes-policy-editor by marmarta for terminal users. By default, it > opens the user policy, but you can specify any policy that is already > registered in /etc/qubes/policy.d/*.policy or > /etc/qubes/policy.d/include/. You can use it with any editor, as you are > editing a temorary copy of the policy, it doesn't matter. Those look very useful! I have one comment to qubes-policy-edit-terminal: when using policy_get() (or policy_include_get()), you get a policy content and a token. Use that token in policy_replace() call to detect race conditions (when something else changes the same policy file in the meantime). > I am doing vim-qrexec, will notice when ready for review, it requires > the qubes-policy-lint for linting the policies from within Vim. So I > will wait for a resolution of this topic. > > Repository: https://codeberg.org/ben.grande.b/qubes-tools Would you like to submit those to the core-qrexec repository? > Attached is my public keys for signing for code (0x00C64E14F51F9E56) and > mail (0x1B7314BF0CCC9687). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRncSgACgkQ24/THMrX 1yxfPQgAieh5yzXC/xsod05WzOaxx4f5XOaNy1MCytK3djJcPmE5AVgHIIPQzqtt HqSPZFrZYKB7MlknUKhztu/auxQw1GR2u3BTQIhDmSpmFVYwjYWaZQPpHiMeQ05P pM1u67+eEFsFHjPEt0mYaDvxA0HIPuIY3+D2ZLIAfUpqUwf3r88GsPJaXXL51OoH 04NJS4fAzL1UW80gk3TCt8aqkc0f5iDrG4ccVDjIn6mEhq01NGXLTPn6JMrvcQCb THhhvWcB0TX+qF/FmKyuAEVUJNSDHCYOwvvuqHTIVuD/9pb1ctHWdCJxBy4Y1xgb 99fckFvJlILcm1UslEdatwPcd/UjPw== =H9K+ -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/ZGdxKa5xF1YlOrnZ%40mail-itl.
Re: [qubes-devel] [PATCH] Fix missing include in RPC names in admin_client
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, May 18, 2023 at 05:49:31PM +, Ben Grande wrote:
> Seems like a copy and paste issue.
> As of know, if I try to replace include/admin-local-ro, as it is using
> the path /etc/qubes/policy.d, the file is placed there under the name
> admin-local-ro.policy.
> For reviewers, check /var/log/qubes/policy-admin.log.
Thanks, applied.
>
> --
> Benjamin Grande
>
> --
> 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/ZGZlKwviLqvWCfJW%40personal-mutt.
> From e684e4c5de379c7412fd256adaf243b73cbff040 Mon Sep 17 00:00:00 2001
> From: Ben Grande
> Date: Thu, 18 May 2023 17:32:06 +
> Subject: [PATCH] Fix missing include in RPC names in admin_client
>
> Signed-off-by: Ben Grande
> ---
> qrexec/policy/admin_client.py | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qrexec/policy/admin_client.py b/qrexec/policy/admin_client.py
> index c28c2f2..f969260 100644
> --- a/qrexec/policy/admin_client.py
> +++ b/qrexec/policy/admin_client.py
> @@ -57,13 +57,13 @@ class PolicyClient:
> self.call("policy.Replace", name, token + "\n" + content)
>
> def policy_include_replace(self, name: str, content: str, token="any"):
> -self.call("policy.Replace", name, token + "\n" + content)
> +self.call("policy.include.Replace", name, token + "\n" + content)
>
> def policy_remove(self, name: str, token="any"):
> self.call("policy.Remove", name, token)
>
> def policy_include_remove(self, name: str, token="any"):
> -self.call("policy.Remove", name, token)
> +self.call("policy.include.Remove", name, token)
>
> def policy_get_files(self, name: str):
> result = self.call("policy.GetFiles", name)
> --
> Benjamin Grande
>
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEyBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmRnbYsACgkQ24/THMrX
1ywVsQf3a2z4HfxPy5/mjI46wPnHYF9cWUTfm2WhxRVbRzi/4ZZ+Y5pgekB391bp
Z35mPlx3R80Op/O+8MY/bjqDsZq5tg4SBRfLAMo16NdegUxqJ8fHvYsSPOBYP07v
F1+p84C7MgsNAOMfC1To6O6gmlI49oXIXEFtLWfxhcYz8oiOnUSvE8ZqBixewBnn
3NOX0g4D6U4OckXo0x9FDBrUcRg2P+JspGDJ9EOoQ8UjixVrzFGdRKMAmVTJ8PIb
qOg3o0uQsdh3zciF2XwSi/q2a5U2zoI3SRV0cUf1gD/okcHp3aPREvA9TUzyVubm
ftACp7FMgvBTBJ9cTnHRXBDQqa0O
=K8Jl
-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/ZGdti976yOjdwhoC%40mail-itl.
Re: [qubes-devel] Proposal 2: Make Qubes OS tools (qvm- and qubes-) consistent with flags and other arguments
on any Qubes OS instance. I think in this > case VMNAME should be optional, without it the tool should output all > possible properties. The issue here is that different VM types may not only different allowed properties, but even different meanings of the same property. See for example 'template' property for AppVM and DispVM. We can probably collect them for all classes and then annotate differences, but I'm not sure how helpful that would be. > * Make the format of arguments providing lists consistent across tools. > E.g. `qvm-ls` has `--tags` with list separated with spaces, not consistent > with --fields and other cases with comma separation. Why not commas? Theoretically it would allow using tags with arbitrary names, including comas. But we don't allow them anyway, so yes, can be comas. Any other places where you found it inconsistent? > * Make tools faster with output, if possible. > E.g. `qvm-volume list` takes ten times more time than `lvs` to provide > similar output for some reason. Up to several seconds in my case. It slows > down every automation process that uses these tools. We did some optimization for qvm-ls before, I guess it's time for qvm-volume now. Thanks for all the comments! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmPPuJYACgkQ24/THMrX 1ywItQf/cc7bJ4RaZR1N6x+hKtysdWGH8Oei2G1vZypYIePtUIOC+kYxdsykVb6Z g2QNN2MO8Av1Dipumtk6OU6lPQWjiGnyyTR9IdvY7PfZjEcPS3XcldVo6To76xzd 7QkE3RZcRbA53fTqc0UJHp5QuxZqP20G+irqSUYg6yrI+1bgCdu3xsddai3h+hpk KqPyWCze2Bwp11sIQWHLcgT4GgNJvQ/jUUhnh3SrGOfeWAXQ1O/K6K1xbSM5iwhq c3dfL2zUL2LFGyP6v6MNNbsrrUKBHboV7XsJkgWV7A78yVI1ew7G2wnWOs8hlspw LyenXMB0sOVVlH7KAKikOM1NL+yFdg== =WorB -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/Y8%2B4lpaBKOSBdb1G%40mail-itl.
Re: [qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmOGK0oACgkQ24/THMrX 1yxWCgf7BmLvUwbMncw1/57OA3h3ZkWpgV/kWfd4gP6U89wOu776ENz6Q6Qdz9hw TtrfQZAnHugODy/uNCqpWxTMj3idWdojWLNxBt5DoACloqhUy9AAQj79wU7YupNU FIBLqE350Oe5jmHJGGrzZKz3Ln0MVR+xxy/hIo9F/4ZV3jqCivR+j8KSoTyhgl80 7lF1NxNG54zJ3lHD0ZH88d0GK+aWuWO2mleaj2Cw2iSUbl+gIFM0jkRNoNcQzjIN ZkCaAtILvpqdDsvK7+fKetHCfKMrY7w/vHElSNUtbZiaGQySZ08JAQahiqVRqGO6 0ixTrQFJF3s04hTekWzgqBN4+iIocg== =rLX1 -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/Y4YrSzc2ee4TPD3M%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 01, 2022 at 12:45:33PM +0100, mm wrote: > Hi Marek, hi Andrew, hi Tobias, > > Marek, I merged your pull request, also merged your changes into master and > added some enhancements and created a pull request. > > Here you could review it > https://github.com/maiska/qubes-translation-utilz/pull/2 > > Either way, one could try it out, there should be no more undefined or > unknown label warnings when rendering the rst docs > and thus could safely imho go and convert the documentation and host it on > RTD. > > Here is a README.md instead of spamming via email > https://github.com/maiska/qubes-translation-utilz/blob/master/README.md > > the configuration should be more readable also: > > https://github.com/maiska/qubes-translation-utilz/blob/master/md2rst/config.toml > > Please let me know if I have to fix further or this suffices. I think the current version of scripts is good :) Thanks! There are sphinx warning remaining, but there are not that many of them and can be fixed manually (things like underscores for headers, or single space at the beginning of line interpreted as unexpected indentation). The only other issue I consider a blocker (but hopefully should be easy to fix) is index.rst. The sidebar index is great, but in its current form it's hard to use - it's very long. I added section captions there and it helped a bit, but I think those should be folded by default (similar folding like sections of the current page). I tried setting `collapse_navigation`[1], but it didn't work. Any other ideas? BTW, while looking for related option, I found you can use `:glob:` in toctree, to add everything from given subdirectory. This way we can have some section filled automatically (as long as directory structure reflects sections, but it is the case in most cases). I uploaded current version to https://qubes-doc-rst.readthedocs.io/en/latest/ (I haven't fixed all sphinx warnings there, so few places may have wrong indentation). I haven't updated translated pages - those are still from previous iteration. Source of the above is at https://github.com/marmarek/qubes-doc/tree/work4/ Another thing that IMO would be better, is to keep the "introduction" page as part of the main website, and only link to it from the documentation. Should be easy with the redirects extension (as already done for HCL and few others). The next question is what to do about qubes-doc repo. We can either replace the current content with converted to rst (and keep markdown in a separate branch, for historical reasons), or create new one (qubes-doc-rst?), and basically archive qubes-doc. In any case, the _doc submodule should be replaced with generated redirects to the new documentation. IMO it can be put into qubesos.github.io repository directly, as it shouldn't really change (it's only to keep existing documentation links on mailing list, forum etc working, shouldn't be used for new content). [1] https://sphinx-rtd-theme.readthedocs.io/en/stable/configuring.html > Otherwise I will briefly handson evaluate weblate locally and report back. Do you have any update on weblate? > @Andrew, > > regarding the minimal debian jekyll vm, here is a way with a template and an > app vm. > > qvm-clone debian-11-minimal jekyll-tvm > > in jekyll-tvm: > apt install qubes-core-agent-networking > apt install ruby-full build-essential zlib1g-dev vim > apt install qubes-core-agent-passwordless-root > apt install firefox-esr git > > in jekyll-app-vm: > echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc > echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc > echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc > source ~/.bashrc > gem install jekyll bundler > find . -name gem # '/home/user/.local/share/gem/' > bundle config set --local path '/home/user/.local/share/gem/' > git clone -b new-master --recursive > https://github.com/QubesOS/qubesos.github.io.git; cd qubesos.github.io.rtd/ > bundle install > bundle exec jekyll serve --incremental > > > > All the best, > > m > > > > On 10/4/22 12:29, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Thanks for the update. Don't worry about the schedule - while we do want > > to finish this soon, it doesn't need to be yesterday. > > > > > > On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > > > Hello Marek, hello Andrew, > > > > > I can have spare time starting Sunday to focus & reply. > > > > > (Please, Marek, recall that i have pointed out mid September that I am > > out off the map > > > > > basicall
[qubes-devel] Default branch switched to 'main'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmOEJNkACgkQ24/THMrX 1yxExgf/TyFKg3F70t1jD+qGjjfqD4/vPhJeCr5DqnTs50/qDwIH3tooE62+Wtl+ DJYQwBxKaRMhErE5Sj0My0AWMGSvYMRgHjlDRQA4vOKu7FMtGQIJyZWXmf7WwUiv rnhCKa5M16Kj3Ne3Jwulg9U8Yjhqr2L9633pLkuOotCQxKeZCyBXlMc1dTK6DzZH wH5Smgh5x2AY5VX4KeSg5HUu/rtRFjxXu4BvpmuwnH8+yg3hoI7dgCTvN56HyooT 0dQWvp5Bc8Xq91rbaNRBiyyUTViGbX3nF26N/zjCvorPChxnJATmJR2YxYk4LQk9 Bq2YlY2176Uz6OeT9/TjLTY/nmVkqA== =J6iF -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/Y4Qk2o2mRjSvbQeq%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 01, 2022 at 12:45:33PM +0100, mm wrote: > Hi Marek, hi Andrew, hi Tobias, > > Marek, I merged your pull request, also merged your changes into master and > added some enhancements and created a pull request. > > Here you could review it > https://github.com/maiska/qubes-translation-utilz/pull/2 > > Either way, one could try it out, there should be no more undefined or > unknown label warnings when rendering the rst docs > and thus could safely imho go and convert the documentation and host it on > RTD. > > Here is a README.md instead of spamming via email > https://github.com/maiska/qubes-translation-utilz/blob/master/README.md > > the configuration should be more readable also: > > https://github.com/maiska/qubes-translation-utilz/blob/master/md2rst/config.toml > > Please let me know if I have to fix further or this suffices. Thanks. I'm a bit busy this and the next week, but maybe I'll manage to take a look. Otherwise, after 11th of November. Do you have somewhere a conversion output pushed? > Otherwise I will briefly handson evaluate weblate locally and report back. Sounds like a good plan. > @Andrew, > > regarding the minimal debian jekyll vm, here is a way with a template and an > app vm. > > qvm-clone debian-11-minimal jekyll-tvm > > in jekyll-tvm: > apt install qubes-core-agent-networking > apt install ruby-full build-essential zlib1g-dev vim > apt install qubes-core-agent-passwordless-root > apt install firefox-esr git > > in jekyll-app-vm: > echo '# Install Ruby Gems to ~/gems' >> ~/.bashrc > echo 'export GEM_HOME="$HOME/gems"' >> ~/.bashrc > echo 'export PATH="$HOME/gems/bin:$PATH"' >> ~/.bashrc > source ~/.bashrc > gem install jekyll bundler > find . -name gem # '/home/user/.local/share/gem/' > bundle config set --local path '/home/user/.local/share/gem/' > git clone -b new-master --recursive > https://github.com/QubesOS/qubesos.github.io.git; cd qubesos.github.io.rtd/ > bundle install > bundle exec jekyll serve --incremental > > > > All the best, > > m > > > > On 10/4/22 12:29, Marek Marczykowski-Górecki wrote: > > Hi, > > > > Thanks for the update. Don't worry about the schedule - while we do want > > to finish this soon, it doesn't need to be yesterday. > > > > > > On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > > > Hello Marek, hello Andrew, > > > > > I can have spare time starting Sunday to focus & reply. > > > > > (Please, Marek, recall that i have pointed out mid September that I am > > out off the map > > > > > basically from 15.09 till 8.10.) > > > > > Nevertheless tried to fix different issues in some spare time, such as > > embedding videos, toctree etc. > > > > > I will push my final version on master asap. (Still haven't gotten to > > the PR/merge/refactor), suggest to wait till Sunday. > > > > > If that is not possible there are several issues to be considered: > > > > > 0. please pay attention to config.toml and conf.py from master and the > > files in preparation. > > > > > 1. which rst files are to be copied (there are 3 atm, since the most > > issues should be fixed via rstwriter2), which to be removed, > > > > > different extensions to be configured such as redirects (I suggest > > leaving an empty hcl.rst (downloads etc) with a redirect, to be > > populated in a > > > > > later stage via jinja scripting), new strikeout extension and new > > role, video directives, which markdown files are also to be copied > > > - is doc.md the right one etc? latex documents are rendered correctly > > (toctree req) > > > > I took toctree-example.rst and manually synced with recent doc.md. It > > seems to work, including PDF version. The PDF could use explicit TOC at > > the beginning, but it is in PDF metadata, so can be seen in the side > > panel of PDF viewer. > > > > > > > 2. !! Problem that should have a solution: > > > > > f.ex.https://qubes-doc-rst.readthedocs.io/en/latest/user/troubleshooting/installation-troubleshooting.html > > > > > in the sentence: > > > > > "Here are the steps to fix this. Note that this allows sys-net and > > sys-usb to take complete control of the system, as described in the FAQ > > here:" > > > there should be a cross reference to FAQ VT-d iommu section but is > > not. (with my ve
Re: [qubes-devel] Retiring R4.0 repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Oct 24, 2022 at 11:24:46PM +0200, Marek Marczykowski-Górecki wrote: > Hi all, > > I'll be removing R4.0 repositories from yum.qubes-os.org shortly. As > README there states, the archive is at > https://qubes.notset.fr/archive/repo/yum/. > > It shouldn't affect anyone using supported version, and those still > running R4.0 (stats say a little over 10k users...) wouldn't receive any > updates from there anyway (we don't build new packages there anymore). > It will result in an error when checking for updates on R4.0 systems, > but that actually can be a good thing - yet another hint that R4.0 > systems are not supported anymore. Sadly, this also breaks upgrade to R4.1: https://github.com/QubesOS/qubes-issues/issues/7838 I'll delay complete removal, but still will cleanup templates repositories (putting a metalink redirect to the archive instead). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNaaokACgkQ24/THMrX 1yzKigf7BbrRDi5arRGEOJltxfpMWWpf40yS/Gsmf/pTZE2cIHOvClHZfCHTW5WC HRHa4Vqkn9wqa7l6pT7EYlNKh7qv2SC/Yh2Ll0ulD9+NQv3bY2i7w9hzue6lpOSN ff8atvIybOhAzOkZx9b8lBga5j6Lps7Exn0SwZzjBglLiH+0Xfpmb49FXqDGnNA7 d+bbuxXPyZOWfZqUFlcR194JSxfGAQfmUX+EYFID8hsIgZOJ6SSm+lyIrvXBkbRD trvdnDeOC9coPnhtKWKxy3vTZGU9Va3c1YmDOhUEoFSFe2Y25zddpU4HH7VjULka wauGyToXRfN8MtbAiObF7iBKQ7U59g== =kOCp -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/Y1pqiFNPICA2eDfb%40mail-itl.
[qubes-devel] Retiring R4.0 repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, I'll be removing R4.0 repositories from yum.qubes-os.org shortly. As README there states, the archive is at https://qubes.notset.fr/archive/repo/yum/. It shouldn't affect anyone using supported version, and those still running R4.0 (stats say a little over 10k users...) wouldn't receive any updates from there anyway (we don't build new packages there anymore). It will result in an error when checking for updates on R4.0 systems, but that actually can be a good thing - yet another hint that R4.0 systems are not supported anymore. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNXAp4ACgkQ24/THMrX 1yzeGQf9FW9DUptd1wuenc6Rjmr/++WGtME5IL0SCI7lYLpnyt91B6P587tqU7e/ c0WYL82PkdndueIpux1uGGinNlM2GECWofrquVosyt16kVYW6TICLWkj+bnEEv+3 7gwrZFlrmNuJaIztFWXolhKm7s3w+O/YEsFrK7/+gQpAT69vvOAqk9kDplRt43EM 2hvaMeyy1UWp/LPR1AfuUgTMGXia1yXq7ZHDv8gA49tVINcudEZJFgxGxHze0QNo jgOeuwxyGUdaZEvshGsRgCBuLZDBEMMEI5n1rP9VYLZolz47Immss1/Pg7Y0cScy GNAfYuQ3ZMrgE8uM8i/nNzgr1LClKw== =owrX -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/Y1cCnh/ToX%2BIYR1s%40mail-itl.
Re: [qubes-devel] Current problems with Qubes 4.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Oct 13, 2022 at 03:57:07PM +0100, 'unman' via qubes-devel wrote: > There are numerous issues being raised about the current performance of > Qubes - graphical glitches, system hangs, random reboots, unstable > service qubes, etc. Some of these are notable when qubes are starting or > shutting down, (which may explain why some people link this to running > updates.) You can see this in numerous Forum posts and on GitHub. > > I think , as djb posted today, this is particularly obvious when > transitioning from 4.0 to current 4.1. (When one of our supporters finds > this, I think we are in trouble.) > I posted about some of the issues in the testing section of Forum, but > no one else commented. I was reporting there issues that affected at > least 5 users, two of them using certified hardware. > Again, if users of certified hardware encounter these problems, we are > in trouble. > > For my part I can probably date these issues back to some time in the > past 6 weeks. Prior to that my Lenovos were solid - I was amazed at the > troubles that some users reported, and my support calls were limited. > This isn't the case now. > > It could be that these issues only affect older hardware - I don't think > so. Or perhaps the current system stresses components so that some > failing elements show otherwise hidden flaws. > > Whatever the case, there's a major issue that needs to be addressed. > I thought of rolling back some systems to see if I can identify a time > before the flood, and then bisect to find which packages might be > responsible. > Would this make sense? > Would it be worthwhile? > Are there any thoughts on the current situation? > What would be the best way forward, and how can we contribute to the > effort? Are those by any chance using kernel-latest? There are numerous issues with 5.19.x kernel, but I believe the default (5.15.x) isn't affected. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmNIjOMACgkQ24/THMrX 1yyIfAgAgf4A2/nw9Bf7wMZ5pjua4S+Fs5fsI+Tz8T7K9aeYmqkZGL8711m2suB2 4Z3d63FHE3pROc6Re4Xj9buDs0omgkyPck0GiB3EtyGmLyvq4f7oDGL9C4Z9VK+a LU1x6MG0F8twNR8nn2LqR7VVw+MWXqbXb1HF44X2gRbkVscQk6riu3vq5zrxuWPU MRKRtKN7S7BkwqefVvHSSjsWSMSpuSfXzUf3PyRXP462qBnpvDs84XhsRFHI0dEl vDyfkWMhs4Oi/5eT9oULMEljRIXfriGOWIwCevMVEuhWXqV/iMgiv0m/12EKLfrZ +CypSQOIx5Ksfa85zAO25DGiVJXXDw== =KDu7 -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/Y0iM5IAWKVsAb25O%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Thanks for the update. Don't worry about the schedule - while we do want to finish this soon, it doesn't need to be yesterday. On Tue, Oct 04, 2022 at 06:54:45AM +0200, mm wrote: > Hello Marek, hello Andrew, > > I can have spare time starting Sunday to focus & reply. > > (Please, Marek, recall that i have pointed out mid September that I am out > off the map > > basically from 15.09 till 8.10.) > > Nevertheless tried to fix different issues in some spare time, such as > embedding videos, toctree etc. > > I will push my final version on master asap. (Still haven't gotten to the > PR/merge/refactor), suggest to wait till Sunday. > > If that is not possible there are several issues to be considered: > > 0. please pay attention to config.toml and conf.py from master and the files > in preparation. > > 1. which rst files are to be copied (there are 3 atm, since the most issues > should be fixed via rstwriter2), which to be removed, > > different extensions to be configured such as redirects (I suggest leaving an > empty hcl.rst (downloads etc) with a redirect, to be populated in a > > later stage via jinja scripting), new strikeout extension and new role, video > directives, which markdown files are also to be copied > - is doc.md the right one etc? latex documents are rendered correctly > (toctree req) I took toctree-example.rst and manually synced with recent doc.md. It seems to work, including PDF version. The PDF could use explicit TOC at the beginning, but it is in PDF metadata, so can be seen in the side panel of PDF viewer. > 2. !! Problem that should have a solution: > > f.ex.https://qubes-doc-rst.readthedocs.io/en/latest/user/troubleshooting/installation-troubleshooting.html > > in the sentence: > > "Here are the steps to fix this. Note that this allows sys-net and sys-usb to > take complete control of the system, as described in the FAQ here:" > there should be a cross reference to FAQ VT-d iommu section but is not. (with > my version this is also a problem) > > Unfortunately the documentation (sphinx referencing via roles, perhaps the > implementation?) is not saying anything how to handle punctuation with > sections and cross ref with ref, > > so as of the moment I do not have an idea, apart from the basic stuff. Yes, I hit similar issues elsewhere. Most of issues like this I fixed by importing objects.inv and taking references from there (this is also pushed to the PR), but there are still few corner cases like the noted above. It seems '&' is handled differently by markdown and sphinx. All the sphinx warnings fit for me on one screen, so I think those few remaining cases can be fixed manually, there is no need to make the converter perfect. > > I also tried explicit automatic labeling above each section with a directive > (.. _id-of-section) - did not work out > > 3. different new files to be considered: > f.e.x 2 versions of the privacy content, how to edit the documentation - > markdown & rst version, visual style guide etc Yes, I left some of them on the old site (with matching redirects), but this needs to be sorted out. > 4. what is done so far on master > > -- video directives > > -- toctree index, notes, schedules, upgrade, how to restore > > -- section cross referencing small fixes > > -- svg conversion to png for selected files and replacement in rst docs > > -- convert leftover markdown links in rst files > > -- markdown redirects > > -- added directives for warning & note (can be used also for indicating > translated content) > -- anything i forgot > > 5. weblate - localization platform should be the way to go imho (sry not a > big fan of transifex rn, weblate is OS etc, > some more objective analysis will follow), there are several issues to be > clarified, wip, tails guys need good questions to work with > - will be done on sunday > 6. anything i forgot, did not address, mentioned too briefly or not clarified > i will address on sun > (if it is still needed) > > all the best, > m > > On 10/2/22 18:24, Marek Marczykowski-Górecki wrote: > > On Tue, Sep 27, 2022 at 01:15:56AM +0200, Marek Marczykowski-Górecki > > wrote: > > > On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote: > > >> Hi Marek, > > >> > > >> > > >> On 9/26/22 00:01, Marek Marczykowski-Górecki wrote: > > >>> Hi M, > > >>> > > >>> In fact, I'm working on translation-utilz right now too. Marta used > > her > > >>> google-foo and found this gem: > > >>> https://gi
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Tue, Sep 27, 2022 at 01:15:56AM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote:
> > Hi Marek,
> >
> >
> > On 9/26/22 00:01, Marek Marczykowski-Górecki wrote:
> > > Hi M,
> > >
> > > In fact, I'm working on translation-utilz right now too. Marta used her
> > > google-foo and found this gem:
> > > https://github.com/SamWilsn/docutils-rst-writer
> > >
> > this looks very nice!! :) Thanks Marta! :)
> >
> > > So, I replaced most of the qubesrstwriter2.py with just this thing and
> > > it's almost flawless (especially tables, images etc work out of the
> > > box).
> >
> > OK, thanks for the PR, I'll merge into and get rid of the obsolete stuff
> > from my branch this days.
> >
> > I have some weird customized fixes all over, but this should work.
I spent some more time on polishing the converter (all pushed to the
same PR), and I think it's good enough already. There are few remaining
issues that Sphinx complains about, but at least some of them look like
issues already present in the original markdown files, and can be fixed
in the RST version manually. I'd prefer it this way (for this category
of issues), because Sphinx gives much better error reporting than
jekyll, so it's easier to iterate.
The rendered content can be seen at
https://qubes-doc-rst.readthedocs.io/en/latest/
And the converted source at https://github.com/marmarek/qubes-doc/tree/work3/
Note the above has already enabled PDF+ePUB version, and German and
Spanish translations (although most content is not translated yet).
I did also used your markdownredirector to generate redirects to RTD,
here:
https://github.com/QubesOS/qubes-doc/pull/1272
It's deployed to wwwpreview.qubes-os.org. It works for most links, for
example
https://wwwpreview.qubes-os.org/doc/secondary-storage/
But, htmlproofer complains about links to specific sections - which
indeed are broken now ('#' part does not survive redirect). For example:
https://wwwpreview.qubes-os.org/doc/#troubleshooting
I don't think that's a big issue in practice, but will require adjusting
htmlproofer call.
Anyway, I see further steps as:
1. Review and merge (or reject) current PRs to qubes-doc. They will
become completely obsolete after conversion. Some of them are waiting
for my feedback...
2. Convert the whole qubes-doc repo to ReST format, and connect to
readthedocs.org as doc.qubes-os.org (any better idea for the domain?)
3. Disconnect qubes-doc submodule from qubesos.github.io repo, and
replace with generated redirects (the content of PR 1272 above).
4. Incrementally fix remaining issues in rst files (at this point, I
don't see any critical ones). Some I see Maya fixed already in the
fixed-rst-errors dir.
5. Adjust documentation contributing guidelines for the new format (this
page actually has rst format issues after conversion, but I haven't
bothered to fix them, because the content would need significant change
anyway).
And then, translation-related:
6. Cleanup our transifex project (remove previous attempts, like
doc-related markdown files)
7. Upload rst version (already done, but will need re-uploading after
final conversion).
8. Setup CI job to pull translations to qubes-translated repo (it's a
single transifex client call, I already have it ready to go from
previous attempt).
9. Adjust theme on translated pages to include warning that non-English
version may be less accurate.
10. Write/Adjust guidelines for translators, open transifex project
again.
The above might get adjusted, if we'd like to use weblate instead, but I
think that's separate discussion (both in practice require migration to
rst first).
There is also a topic of translating the website itself, which IMO will
become much easier once documentation is moved away.
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmM5uy8ACgkQ24/THMrX
1yySHgf/SPQD43P6rlOVYTQ2ESs8C5i+NKl8VpanV7EOOydXCVwBSe97Liu/Z7xv
haNyGCVSPs3/SYjRMBhMrH5TbL39KSchT4v37DMuy7DeohX5tpS9XC+p/GpecFze
V6gjuEOR47wSxoo6eFYVrn74zn57fCHiOmzms7MrDH0pmUOHlTQVb5qBVlm6SAwm
tIYFmsfAzqeSYn61FgnQ11iNBXSUZVwiG5991BvkZuSkTBe6Y9HT3AJcOwrjDFh3
D79yFE+iDi4qSJHpdvOoARtHQPMXJEn+Ou9xl+g0WGzTusayB/f/2fPkhtruigtb
CLJwWw+jr0+Q5dTdc8kZuVCsENGn7g==
=Do2o
-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/Yzm7MFZFrNbkBS33%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Sep 26, 2022 at 11:33:22PM +0200, mm wrote: > Hi Marek, > > > On 9/26/22 00:01, Marek Marczykowski-Górecki wrote: > > Hi M, > > > > In fact, I'm working on translation-utilz right now too. Marta used her > > google-foo and found this gem: > > https://github.com/SamWilsn/docutils-rst-writer > > > this looks very nice!! :) Thanks Marta! :) > > > So, I replaced most of the qubesrstwriter2.py with just this thing and > > it's almost flawless (especially tables, images etc work out of the > > box). > > OK, thanks for the PR, I'll merge into and get rid of the obsolete stuff > from my branch this days. > > I have some weird customized fixes all over, but this should work. > > One question though: > > have you had success with parsing admin-api.rst (as converted by pandoc from > md?) I think so, yes. > > I get the error when parsing with docutils in order to post-process it for > qubes: > > docutils.utils.SystemMessage: /home/user/testingfilez/admin-api.rst:74: > (SEVERE/4) Unexpected section title IIUC this was issue with overly wrapped table, so '_' or '-' in some cells landed at unfortunate locations and were mis-parsed. In my PR I set line length much longer to avoid this table wrapping and it seems to work. The final sphinx-generated HTML looks a bit weird (no vertical cell borders), but I think that's up to the theme, not RST. > and it cannot get over the table as it is...:/ > > all the best, > > m > > > > > > I massaged the links fixup a bit, and now the only thing it complains > > about is arch-spec-0.3.pdf, and a single "c" lexer issue. That's all. > > Lists starting with non-1 number works too. > > > > I'll push my state in few minutes into separate branch. > > > > BR, > > Marek > > > > > > On Sun, Sep 25, 2022 at 11:31:22PM +0200, mm wrote: > > > Hey Tobias, > > > > > > > I do not know unfortunately what you are referring to? > > > > > I mean the objective is to convert the markdown documentation to rst > > asap > > > > > Unfortunately it did not work out out of the box, due to docutils > > niceties. > > > > > background: I refuse to publish my regular-expressions-monster-convert > > > script. > > > > > I had to write a new one using docutils, as it should be. > > > > > Status as now is: > > > > > there are some minor fixes to be dealt with, such as container for > > > video-tours directive, registering of doc and ref roles > > > > > and a directive for strike through handling, so that the conversion > > can be > > > done with minor headaches by the qubes os team > > > > > (hint: I just pushed master branch on qubes-translation-utilz where the > > > current status can be feared :) ) > > > > > > > Regarding translation as a whole: Michael suggested weblate, as tails > > have > > > experience with it and it seems very nice as OS alternative to > > transifex. > > > Once there are further infos on that will summarize and write. > > > > > Do you mean that or smth else I forget to mention here? > > > > > All the best, > > > m > > > > > On 9/17/22 20:43, Tobias Killer wrote: > > >> Hi, m, > > >> > > >> thank you for all the work! > > >> > > >> As far as I can remember, you talked with Marek about i18n and l10n on > > >> the Qubes OS summit 2022. Could you (or Marek) please give us a summary > > >> of the results of those talks? > > >> > > >> Thank you! > > >> Tobias > > >> > > > > > -- > > > 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/75e76fab-da0d-058f-c8e9-4db4006c15ed%40maiski.net. > > > > - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMyMqwACgkQ24/THMrX 1yxvdQf/edqGoIOTCO+vUWbGhcga0TtFZ3Wusa3nhk0fAzlZeWMcAtnu002UH86R fUwIhlLnpxGBOsbqIOVZV6LKGV86sMSAsxdkrGBil2dzdzcSk7T+c9SerI8JcTDe T2OehXRyelbjUVCVX41gKKR2J5mFfp+5Xo7/QLhaquLC9AIZs+k6WPpcp0C8LIO6 NIrxW5uyDs2u4bf2RJaggH1U6x2RD2qQADAPP9t7DR+5lfUW841ZkPCPBC9NBNbV dShnuSWD2XnTZPfzAhjQiSG+b196Uc8rt/lHUOJYgis7qZ438W/G5ZG/DDu+B1XG SvF1C+1zaDwqUhpWTRZLIG2KvfRzVg== =qAw9 -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/YzIyrHM/M8kP6qEe%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi M, In fact, I'm working on translation-utilz right now too. Marta used her google-foo and found this gem: https://github.com/SamWilsn/docutils-rst-writer So, I replaced most of the qubesrstwriter2.py with just this thing and it's almost flawless (especially tables, images etc work out of the box). I massaged the links fixup a bit, and now the only thing it complains about is arch-spec-0.3.pdf, and a single "c" lexer issue. That's all. Lists starting with non-1 number works too. I'll push my state in few minutes into separate branch. BR, Marek On Sun, Sep 25, 2022 at 11:31:22PM +0200, mm wrote: > Hey Tobias, > > > I do not know unfortunately what you are referring to? > > I mean the objective is to convert the markdown documentation to rst asap > > Unfortunately it did not work out out of the box, due to docutils niceties. > > background: I refuse to publish my regular-expressions-monster-convert > script. > > I had to write a new one using docutils, as it should be. > > Status as now is: > > there are some minor fixes to be dealt with, such as container for > video-tours directive, registering of doc and ref roles > > and a directive for strike through handling, so that the conversion can be > done with minor headaches by the qubes os team > > (hint: I just pushed master branch on qubes-translation-utilz where the > current status can be feared :) ) > > > Regarding translation as a whole: Michael suggested weblate, as tails have > experience with it and it seems very nice as OS alternative to transifex. > Once there are further infos on that will summarize and write. > > Do you mean that or smth else I forget to mention here? > > All the best, > m > > On 9/17/22 20:43, Tobias Killer wrote: > > Hi, m, > > > > thank you for all the work! > > > > As far as I can remember, you talked with Marek about i18n and l10n on > > the Qubes OS summit 2022. Could you (or Marek) please give us a summary > > of the results of those talks? > > > > Thank you! > > Tobias > > > > -- > 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/75e76fab-da0d-058f-c8e9-4db4006c15ed%40maiski.net. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMwz8cACgkQ24/THMrX 1yx55gf+L10gTE4rcdKYNE6QVAZQNfpZvuMiCooS19Ik2hy3cAqEnVtDoxSRnuOr jr2NY8vroAEFEoD4U1QPRhOe1HeRL81+9zfTdIVZfKXBCxXSiZMlZuh0LHJYvh5X wE5Skry+ObVjiqA8amb/AeI2Y2LXFAWlV6k0YuwOm5J8/TFu6pe5jKQdaapg5+qa LLtC5tO+g2BcXEhkhFhhvBS/ABJD6vUjWjvdWdQtdnfhPnOgYTKEYXFiNFMPgs8Q 6ClhzILwVghws7frJJ0eOQ8JvbC+OTHAd3KJJZe5M1kAbu6rQIS7XCSOJ222WSSQ NhggXUNW8D1sWkLOWeCgA2QaVReNpQ== =npHQ -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/YzDPx/CP7LOHnLz%2B%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
e sub-section but not the main index? Or not linked at all? Some of those are normally linked from the website footer, https://www.qubes-os.org/intro/ or similar. But generally, IMO better have every doc page linked to the main index. > Regarding the old translation markdown workflow - it is still there, and can > be brushed off the dust. > > P.S. I just realized that my .vimrc config was broken. Please excuse the > tabs...! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMV47oACgkQ24/THMrX 1yw1sgf/fW9F3s/Bp1/NmqH4lBH/9jy/p49/lYs8UTU9qWWw8sJY9w6v8rVZ/N3F okWW30Pjw8j1DPx6zY9JWdvzYu9jZAABgHOLNrYY9u4O2WD9V0CFUbZNxezqDyGR rNe8XGdWrWoPDylRW7EYw4BTC6m7RPHK7h3GuyoP0YyTyxDim0+9I4vzgq304uBB NiUJLCdzRaW2x1S5ulJbgSd6iDYdiz2mGuvkaS/hbqv+OnaMkHLaOJmKaLShWY6g Z5dU2tDprpx0ohkXIfd9hTvijrDrb981qDP3pjFY2bXoFFrTaHgUn6myXFCKl5tW F728mHFxzq2LxH1XzCiFeneJ+Qg47Q== =eLlL -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/YxXjuoYSGsH17fUI%40mail-itl.
Re: [qubes-devel] qubes-doc & rtd
structured text (w pandoc f.x.), > which is native for Sphinx, and thus, many of the current rendering issues > should be non-existent. > > One could convert the md to rst as in > > ``` > pandoc doc.md --from markdown --to rst -s -o doc.rst > ``` > > one can view it with restview (pip install restview) > > > ## RTD problems/TODOs > > > 1. Rendering > > There are warnings that have to be adressed such as: > > ``` > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/user/advanced-topics/awesomewm.md:22: > WARNING: Pygments lexer name 'shell_session' is not known > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/project-security/verifying-signatures.md:150: > WARNING: 'myst' reference target not found: /support/ > /home/user/qubes/qubesos.github.io.testrun/_doc/docs/source/user/troubleshooting/vpn-troubleshooting.md: > WARNING: document isn't included in any toctree > ... > ``` > > 2. Many broken links > 3. PDF - the documentation is not being rendered correctly > 4. EPUB - the documentation is not being rendered correctly > 5. Sphinx uses the Jinja templating engine for its HTML templates. Meaning > for files like > > https://github.com/maiska/qubes-doc.testrun/blob/49253a1f5a24a9a9f5c1c42e2395ca494a1e4b4b/developer/general/style-guide.md > > > this is the result: > https://qubes-doctestrun.readthedocs.io/de/latest/developer/general/style-guide.html > > > I have not found a converter from liquid to jinja, so there should be > another solution > > 6. External files: can be just listed in the doc.md and the markdown files > can be deleted. But the redirects are to be handled > 7. Warning: RTD is somewhat buggy if one pushes immediately one after > another several branches for one project that are activated > 8. Find out how to handle multiple translations with one repo in RTD > 9. Uploading to transifex problem (wip) > 10. Analytics (JS in general in RTD): script as in [14] with a RTD section > regarding this [15] > > > What are your thoughts on this? Let me try to resurrect this thread :) First of all, thanks again for all this analysis. I think indeed RTD is the way to go. We'll have occasion to talk about details on the upcoming Qubes summit. Personally, I wouldn't exclude an option to convert documentation to ReST format, especially since we get several more features then (better internal links tracking, PDF/ePUB generation, built-in macros for notices, warnings etc, and several more). But of course this needs to be weighted against other factors like complexity of the conversion itself, or ease of use for maintainers and contributors. See you soon! > All the best, > > m > > [1] https://github.com/ultrabug/mkdocs-static-i18n > [2] https://github.com/mondeja/mkdocs-mdpo-plugin > [3] https://docs.readthedocs.io/en/stable/localization.html > [4] https://myst-parser.readthedocs.io/en/latest/ > [5] https://www.sphinx-doc.org/en/master/usage/markdown.html > [6] https://myst-parser.readthedocs.io/en/latest/sphinx/intro.html > [7] https://myst-parser.readthedocs.io/en/latest/sphinx/reference.html > [8] https://www.sphinx-doc.org/en/master/usage/theming.html#builtin-themes > [9] https://www.sphinx-doc.org/en/master/usage/theming.html > [10] https://sphinx-rtd-theme.readthedocs.io/en/stable/configuring.html > [11] https://sphinx-themes.org/#themes > [12] https://docs.readthedocs.io/en/stable/guides/adding-custom-css.html > [13] https://github.com/sphinx-doc/sphinx-doc-translations > [14] > https://assets.readthedocs.org/static/javascript/readthedocs-analytics.js > [15] > https://docs.readthedocs.io/en/latest/advertising/advertising-details.html#analytics > > -- > 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/f24cb2b0-9465-ef3c-c71f-afb71248ab9f%40maiski.net. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmMSIcwACgkQ24/THMrX 1yw03Qf/c63FuOGz6zsBwRWMLabRM3JxCA05ILFu76bg3/MI68DtbiRcYEBnCekR CbvNIxTLq077X4N58HiIlsunhrln+n2eLgsD6H/ljp3ZGmbNdzfZhz2WdbWMaKjK 4dzdxEb6pUfrDqXrNOrxDOxRHBJYLR6mjr2ih211iPVaJccgIny8l8zSkWpTmG6S JmowbLeaxfNXsv00yODQ9Hv/7hTZj5xd0Kntq17FGrL9BWLFad0fVYxzZ93Dh6NI g6KgSnwWAvLqUZjQ7BSrjhbXuKUOeIHJ+luA23aqKioWHNcA9SXvtz2bUZyYVNeM Eve3568YYj12PcZIjbZH+3leDZ+EbA== =kYM7 -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/YxIhzCN82osQq9VK%40mail-itl.
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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. 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. > > (*) Maybe split-gpg2 should include a separate qrexec service that just > > exports all the public keys from the backend? It could save the user one > > qvm-copy call... > > It absolutely should for multiple reasons, not least of which being that > it allows for easily maintaining a shared public keyring. One can > maintain a shared collection of public keys in one qube, and other qubes > can import keys from it as needed. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLXW6EACgkQ24/THMrX 1ywX+wf/YOC9+ITgbycY3ebCBuH00Pwe1tr13Bs/rxe1eNClwRnBSCdPpSKbYwcQ 2plQXFE7woIqw25diVYCWKnjAc6kQJdhpVCCkTrCOwntKSg/+54YmPXMzXr6Q3SJ p5uAvU9ej4RvQ+FZnviEQvIFEM5OmEFizabRssEwGrD7R8N5C
Re: [qubes-devel] Security concerns with split-gpg1 to split-gpg2 migration
port for exactly this scenario, see the > --export-secret-subkeys option. > > From the manpage: > > --export-secret-keys > --export-secret-subkeys > [...] > > The second form of the command has the special property to > render the secret part of the primary key useless; this is a GNU > extension to OpenPGP and other implementations can not be > expected to successfully import such a key. Its intended use is > in generating a full key with an additional signing subkey on a > dedicated machine. This command then exports the key without the > primary key to the main machine. 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... (*) Maybe split-gpg2 should include a separate qrexec service that just exports all the public keys from the backend? It could save the user one qvm-copy call... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmLOyjIACgkQ24/THMrX 1ywntwf9Fh6CObD3ZZRFWm08bkXJYld8C4oap2FqVJ2UuHJfO8GG1LWC+l8TDeCi duXaHxHK/BfCdxhiMDxrpPL63wam64s56PFjSalr51ranEyCLlm+GF3Qgp7PE+av xgblUBg9IqbqOGyFrcWELa9667OxS5Uq5JTmiisNJfwToBRBVgSfw0rzxcbNpErU Nej/dO7eCrw0YL9L7unbvyLj/Gk6Z833Tn446wfa0UAd2TK1oB5tvcoF9umLleCn pXN+RJuoKDYgatsF4txh3+OO8qufn/wPyUmnspFMeOJ+x3NjpUSt+GaTyKdljaBm pEH3M1mvvmTj2QhRcuHitAtLnACq+Q== =28dJ -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/Ys7KMlhEYz9e3CFx%40mail-itl.
Re: [qubes-devel] Write access to standalone's Lv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 26, 2022 at 08:36:29AM -0700, Pin dev wrote: > Hello, after an update I don't have qubes-core-agent anymore on a Debian > standalone VM. > However, I did not set a password to the user "user" and root account is > disabled, so I cannot login anymore. > I tried to losetup loop43 /dev/qubes_dom0/vm-dev-root but it appears to be > busy. > After that, I tried to mount /dev/qubes_dom0/vm-dev-root /mnt but it says > wrong fs type. > > Is there any chance I could get back write access to that private volume? Take a look at this doc: https://www.qubes-os.org/doc/mount-lvm-image/ But also, if you haven't restarted that template too many times, you may be able to revert the last update: https://www.qubes-os.org/doc/volume-backup-revert/ - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmKPrWUACgkQ24/THMrX 1yyXsgf/ang8jKCUVKvM8y5Y0VZykp8T4V5ur7S+PAzYRqozefZkbe8HlAEL2el7 yWGlX+bHvb640O3bNZA/BZiQ9NnkJV1hpcbHBFSo1buKTWc37bDGGvfawLZl0bhe weLlU9+uLoR2J/s38b5awDQshGeQN8Af3Y5v8Eb9rd3Cmi/Y0c3n12Qmxn2DPnHw irIzHBf5vHMNYN5HSALcPA/RpOXcvZsG8lmfbVhe2UKnmrrZlYeNuj7x9FobcOtK 1s42h60kyuuvuFOyqlJsZU0hn2NmERxqZn3wkL/xSwMDRiy9hKXxT8T7nI+4cTP8 fStkhMrmDOzDD4LiW1eqn5uRwaB1Gw== =3u48 -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/Yo%2BtZsed8Szk4s%2BT%40mail-itl.
Re: [qubes-devel] GitHub ticket #5929 disappeared (official Arch Linux template)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Wed, Apr 20, 2022 at 12:32:56PM +, Rusty Bird wrote:
> Marek Marczykowski-Górecki:
> > On Mon, May 10, 2021 at 11:56:51AM +, Rusty Bird wrote:
> > > Marek Marczykowski-Górecki:
> > > > On Mon, May 10, 2021 at 10:27:38AM +, Rusty Bird wrote:
> > > > > I was trying to check on the status of the Arch Linux template, but
> > > > > the issue ticket[1] has disappeared ("Page not found"). Maybe it's
> > > > > caught in a GitHub spam filter?
> > > >
> > > > Likely yes, for some weird reason. I've asked github support to restore
> > > > it.
> > >
> > > After a couple of GitHub API requests, it looks like they're currently
> > > memory-holing 43 issues:
> >
> > Thanks for the list. Based on it, I've searched the github export I do
> > from time to time, and I can confirm most of them are not spam (at least
> > looking at the title, haven't checked the body).
> > Specifically this list:
> > https://github.com/QubesOS/qubes-issues/issues/1004
> > https://github.com/QubesOS/qubes-issues/issues/1017
> > https://github.com/QubesOS/qubes-issues/issues/1025
> > https://github.com/QubesOS/qubes-issues/issues/1127
> > https://github.com/QubesOS/qubes-issues/issues/1510
> > https://github.com/QubesOS/qubes-issues/issues/1678
> > https://github.com/QubesOS/qubes-issues/issues/1794
> > https://github.com/QubesOS/qubes-issues/issues/2196
> > https://github.com/QubesOS/qubes-issues/issues/2221
> > https://github.com/QubesOS/qubes-issues/issues/2669
> > https://github.com/QubesOS/qubes-issues/issues/2804
> > https://github.com/QubesOS/qubes-issues/issues/2862
> > https://github.com/QubesOS/qubes-issues/issues/3119
> > https://github.com/QubesOS/qubes-issues/issues/3272
> > https://github.com/QubesOS/qubes-issues/issues/3358
> > https://github.com/QubesOS/qubes-issues/issues/3395
> > https://github.com/QubesOS/qubes-issues/issues/3402
> > https://github.com/QubesOS/qubes-issues/issues/3414
> > https://github.com/QubesOS/qubes-issues/issues/4037
> > https://github.com/QubesOS/qubes-issues/issues/4056
> > https://github.com/QubesOS/qubes-issues/issues/4107
> > https://github.com/QubesOS/qubes-issues/issues/4108
> > https://github.com/QubesOS/qubes-issues/issues/4240
> > https://github.com/QubesOS/qubes-issues/issues/4605
> > https://github.com/QubesOS/qubes-issues/issues/4690
> > https://github.com/QubesOS/qubes-issues/issues/5033
> > https://github.com/QubesOS/qubes-issues/issues/5083
> > https://github.com/QubesOS/qubes-issues/issues/5154
> > https://github.com/QubesOS/qubes-issues/issues/5204
> > https://github.com/QubesOS/qubes-issues/issues/5205
> > https://github.com/QubesOS/qubes-issues/issues/5325
> > https://github.com/QubesOS/qubes-issues/issues/5334
> > https://github.com/QubesOS/qubes-issues/issues/5582
> > https://github.com/QubesOS/qubes-issues/issues/5928
> > https://github.com/QubesOS/qubes-issues/issues/5929
> > https://github.com/QubesOS/qubes-issues/issues/6415
> > https://github.com/QubesOS/qubes-issues/issues/6422 (dupplicate of 6415)
> > https://github.com/QubesOS/qubes-issues/issues/6451
> > https://github.com/QubesOS/qubes-issues/issues/6452 (dupplicate of 6451)
> >
> > That said, many of them are misplaced and were immediately closed as
> > "invalid" as they should be rather posted to forum or ML.
> >
> > I'll add them to the list in github support request...
>
> Did you ever hear back from them?
Yes, a month later, and it's not very optimistic one:
It appears that these issues are currently hidden for reasons relating
to the accounts that opened them.
I'm unable to provide any further information about this for privacy and
security reasons however if the account holders reach out to us we may
be able to assist them directly.
Unfortunately we're unable to re-show these issues until such times as
we can work with those account holders.
Sorry it's perhaps not the news you were hoping for but please let me
know if you have any other questions.
> 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 act
Re: [qubes-devel] systemd rescue mode vs qubes root account locked
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 08, 2022 at 12:13:20AM +, Holger Levsen wrote: > hi, > > recently I had some hw issues which I needed to debug so I tried > booting with systemd rescue mode (by appending systemd.unit=rescue.target > to the kernel cmdline) but that failed because the root account is locked > on Qubes. > > So I'm wondering what is the recommended resuce mode for Qubes? booting > the installer in rescue mode or setting a root password or??? Generally, booting the installer is more reliable in some cases, since it doesn't rely on dom0 being in any usable state. But since that may be inconvenient at times, you can get shell in initramfs using 'rd.break' on the kernel cmdline. Or, if you just want to avoid staring any VM, use 'qubes.skip_autostart' option. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmIB1XAACgkQ24/THMrX 1yyvdQf7B5DOOpr+BcEJv1l2rUPyXHEmbpNm/ird6SnTpyqso9ljwQq7NsQBLCcH JpWnllx1FWgzHtikhOojHXIhvUesRyWBbzmo+k6c2N6WK8Bbym7FbcdtkbIDEMHO fTXhR+Osr6cAfoQJUiyp0wfG5hzFUAM1mDTi8vlXEcNa02zEH7IQqsLAhO8Zl30z 3X6qTx+3v5aLxqCI3ZaD2TEBnGWzOowZutGSsAtgA5lGtflwmQeaBglVmXYLbbLX iKu1pvWLDA8dr8+mYu0xaAFTAVoNn9DfTfD1An/YHMtLATmEdQF3v0rdtpbohA2N HBsmOAjkPP8HyjQ4981ngcXqeQ5gIQ== =uemw -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/YgHVcAqrEtbZcCVN%40mail-itl.
[qubes-devel] There will be 4.1.0-rc4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Just letting you know that there will be 4.1 rc4, because of few bugs in the stubdomain / gui-agent there, which are rather severe (including GUI for Windows VMs crashing). Specifically those two: https://github.com/QubesOS/qubes-issues/issues/7148 https://github.com/QubesOS/qubes-issues/issues/7164 There are few other issues that we will fix, while at it. I'll update the schedule shortly. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmHWbIEACgkQ24/THMrX 1yweXAf+OkeFqk3szYIp5MS9unNDbH1A4IJJlMx7aCUIvmfotJG53lOjA7gKQsvK H0EIO+MRA5udD88Hfza+wYJNYGrnx8UMzbpak+mOegscIz11He4NGXRgkWbXZt4X PAK3PCi5HXP+D1vept2JeSW6on+9d2m27q+1NuBUp2Ekii0KvsGxqV/RCYobz+B6 JpCIu6LtPWuhK0gqfyxa7GRA+I7Mg5aip/Bwbqq/z3/bGsMMi1cD0Cl8XFTbGYn7 xTksecDJKNzZ8Oi+/Efh3EUgAxgOa4hm0l7dujurRswAb97tL+vcJWUDlKfsijpW YQ4/uMEJ4EHzqY4Hrs5De0C/pkslDw== =fvfA -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/YdZsgqPyyD%2B4PCLr%40mail-itl.
Re: [qubes-devel] Contributing to hardening AppVMs templates
the responsibility to Dom0. It looks to me > very > feasible to create a file system accessible by both Dom0 and the AppVM where > AppVMs can transfer the files to be manipulated and then execute those actions > from Dom0, not only the confirmation step. No, that's backward. Filesystem-level sharing is rather complex thing, with a huge attack surface, we definitely don't want to expose dom0 to such attacks. When you design your data flow, you (currently, unfortunately) need to think how do you trust components involved. Making transfer trusted->untrusted->trusted slightly(*) less risky is not very useful. If you need such transfer (assuming here you trust the "original" content of downloaded data), simply use appropriate VM to download the file. If in doubt, use (fresh) disposable one. If you don't trust the original content, there are still few things you can do: - for pdf and images, we have tool to "clean" them up[9] - for others, you can always open them in disposable qube, including extracting the data you actually need there (in your very example - open such tar in a disposable qube, and qvm-copy only the content you need - and still treat it as untrusted) (*) Your solution is only about ensuring the file that is sent is the one that got written. But does not cover several other parts: - is correct data actually written (substitute file at download stage, instead of qvm-copy) - is the tool used to preview the file actually showing you really the right content (substitute file at preview stage) and probably few more. > Would anyone kindly give me some hint about were I can start to achieve > this? You can start by checking https://www.qubes-os.org/doc/contributing/. Things like wrapping Firefox (and possibly others) with firejail sounds like a good idea for the start. To keep things nicely organized, IMO it should be a separate repository (and separate rpm/deb/... package). You can use for example https://github.com/QubesOS/qubes-app-linux-snapd-helper as a skeleton. BTW, your appendix A is rather complex, there are much simpler ways. Hint: qvm-run --localcmd. The lack of network in dom0 (and templates) have two purposes: 1. Make it harder to get _into_ dom0. 2. Avoid _accidental_ untrusted data download (like, your favorite desktop configuring tool trying to download you a wallpaper from http://some.random.website/). If you are in dom0 already, your options are rather limitless. Breaking naive connect-back shells is rather poor consolation. [1] https://github.com/QubesOS/qubes-issues/issues/4239 [2] https://github.com/QubesOS/qubes-issues/issues/4088 [3] https://github.com/orgs/QubesOS/projects/5 [4] https://www.qubes-os.org/faq/#what-is-qubes-attitude-toward-changing-guest-distros [5] https://github.com/QubesOS/qubes-issues/issues/6877 [6] https://github.com/QubesOS/qubes-issues/issues/6366#issuecomment-767635670 [7] https://github.com/QubesOS/qubes-issues/issues/7130 [8] https://www.qubes-os.org/news/2020/03/18/gui-domain/ [9] http://blog.invisiblethings.org/2013/02/21/converting-untrusted-pdfs-into-trusted.html - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG8B84ACgkQ24/THMrX 1yxjiAf8Day2jC1Mq6i6WVsvUUPe2m3q0e/StY+5QJDSRk7k0RLx9XZYgd85S0NP +eCq7WtRo0KCBidVm8rIl20f3cPzTdORNM2MwaSqcMqy3562NzEXbNJT3mj3lb4O euf1ICMFY+AGnq0SvIkNAszFG0WljfjcxlQpVeHT112hct8hsFhwgFdngbvI/Ueq pFsdHnDFTBbmvkA/x4AjmP+urE5E+z9ZM1KsAuUQx53q/9uXK+vW1IZeiIHGA9Cl jqDsSDAN0YTNii4FldQFBGLlVSUTJcojbM4bW2TtOOLZUDKX21FdcVooB7sARZXz zhzyjWjvUUSKahSiC8nXjo6/lXy0yg== =uvJs -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/YbwHzsdq0wRpEced%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Dec 16, 2021 at 01:27:43AM +0100, Manuel Amador (Rudd-O) wrote: > On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote: > > Here is how qrexec policy prompt is doing it: > > https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 > > Bad news, I did not understand any of that code. :-( > > Just to see if I understand at least the process: > > 1. dom0 sends RPC `policy.Ask` to GUIVM > 2. this policy program pops up a dialog > 3. the response comes back Yes, exactly. > If this is correct, please let me know if my following theory is correct: > > 1. I create a `policy.AskBlah` policy with the same config as `policy.Ask` Since it's dom0 who make the "policy prompt" call, you don't need a policy for it. > 2. I move my program that asks via UI to the package to be installed in >the GUIVM Yes. > 3. I also move my RPC service code to that package You mean the ruddo.AuthorizeFolderAccess service? No, that stays in dom0. > 4. I make my dom0 RPC that (today) executes the GUI program, invoke the >policy.AskBlah service, and await a response Yes. > If so, how do I distinguish between the case of GUIVM and no GUIVM? You check for the source domains's "guivm" property. If it's "dom0", you call `/etc/qubes-rpc/policy.AskBlah` directly, otherwise you call it via qvm-run. > Additionally, what about the folder share manager application? It currently > runs in dom0 (kinda has to, because dom0 is where the file share policy is > stored). Yes, I guess it should remain in dom0 in this design. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6ir8ACgkQ24/THMrX 1yzVWQf/Q9To2pFR5hATlzRGzYjXyhSVvzG+P0joXitkc+rbZ7T6gAlwkwRqNm2L ZQzxQgkAlUZ+xOvGv2w1nE+sxwHd5c5cvAe8WKnIA6oiEUnfN+y5MDuK7iBCUMGB ZAtkcVynomXYiNhLwUw+4EYuNKSeWMcVWH18RhChVp99XXfkr3kWlzjofGe1VCNK +660MsfMlmw3whZegzpQ7sYFfF1TGSoojKKUwrrSmWEoImR0YPpabmOwQGWV0rQl KYmQOUYuYmQiBx8T/J+bCp5YnOAfJnGIUw1AHMgKbubSQN6lqnMHwOgHXoWOo9mv f5NMsiLv9SLrRMarFLsC/TobHB7RJA== =C9IM -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/YbqKwH6Dd0ZgMdlU%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Dec 16, 2021 at 12:17:44AM +0100, Manuel Amador (Rudd-O) wrote: > Prefacing this response with: > > I went with the implementation as designed by the document. In the future I > will revise argument passing to use the new 4.1 style, instead of base64 > over pipes. Currently the implementation uses a custom-made dialog — a very > nice one, if I do say so myself — in the spirit of the feature request > #5853. :) > On 14/12/2021 15.28, Marek Marczykowski-Górecki wrote: > > I think it looks ok. Regarding one-time access, I'd rather specify it > > with a timeout, to avoid cases when the client VM requests authorization but > > uses it much later. > > This will land in the project's to-do list and will be implemented at some > point in the future. Patches always welcome! > > > > > One thing you may want to consider is interaction with GUI domain - in > > this case dom0 couldn't directly ask the user, but rather ask the GUI > > domain to display the prompt. We do this for normal policy prompts. > > Anyway, it's of course up to you whether you support GUI domain or > > not... > > Yes, I intend to support the GUI domain. *How do I do this?* Right now my > code merely spawns up, from dom0, a GUI dialog using DISPLAY:=0. This was > lifted from other parts of the Qubes repositories. If going with standard qrexec prompt (+#5853), you'd get that for free ;) Otherwise, you need a qrexec service that calls into GUI domain to do the prompt (and then validate its output to really allow only the thing that was asked about, not something else). Basically, factor out the prompt code into separate file, then call it via `qvm-run --service ...` instead of directly. Here is how qrexec policy prompt is doing it: https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6g08ACgkQ24/THMrX 1yyy/wf+MP+ZLD3cgBPZivLwOaIyZGWn6I/nmaCEQnmjv6xnUw/gp37fEJIaDn1p olyP4egGDSb0pDgf9F2JUfPNX9iO59AUdmxkq7tuQWNzP/Hp8vtcFR3vzS4Sug9H TCW40s4KR3YMRR/I2icTe8KvuCqYrt7gE2WEFxuQ256OJtUM5VTfHZaEX4iy6MU9 P568+i34F7IEmj4p9ZvYAQBDgZXiuFCDi5Xo37Ma5U9kG8SQEwiPS9q5PTNkF065 N3sQqW+J1XDAIZRa2fAGnKcRwAFFm9Xdnap3JhaoiWlk5CaSJLWinLD/qH9WEbo7 /swlVqBnPt0uc/tWjuOi1UAt4dw7Ew== =yfj2 -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/YbqDTxMnZI5DINZi%40mail-itl.
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Dec 13, 2021 at 06:58:02AM +0100, Manuel Amador (Rudd-O) wrote: > Hi folks. > > I wrote the Qubes shared folders service in an afternoon. It is what it is > -- useful, but not ideal. > > I've come up with a design for an improved version that I would like you to > review for correctness and to see if it could be implemented better. I > think this design has potential, and I want your feedback before > implementing it. > > The document is at > https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md > — I am adding the contents of the document below. Please go ahead and > analyze it. Thanks in advance for your feedback. > # User interaction > > What we propose is the following: > > 1. The user instructs the client qube to mount folder `X` on the server > qube. > 2. dom0 asks the user "client qube wants to mount folder `X` on server > qube". > 3. The user responds accordingly. If authorized, the connection is > permitted and the client qube can successfully mount `X`. > > The Qubes policy argument mechanism is insufficient for the proposed > interaction. For one, it limits the argument size to 64 bytes This is no longer the case in Qubes 4.1: https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/#performance-improvements (the limit is now ~64k) > , making it > unsuitable for a wide possibility of paths the user might want to connect > to. Second, it doesn't actually convey the information that the client qube > sent — it conveys a form of hobbled information that crucially does not > include spaces, slashes, or other special characters, all of which are > legitimate in POSIX paths. There are ways around it - encode the path. We do that for qubes.VMExec service for example: https://www.qubes-os.org/doc/vm-interface/#qubes-rpc This way, the argument itself is still safe to process in various tools (even log4j :P), and represents almost friendly path - /home/user/Work/project-X would become -2Fhome-2Fuser-2FWork-2Fproject--X. > Third, the way that the question is presented is > not exactly usable. This is indeed a problem, especially the user would see only a mangled path, and no info that the thing is indeed the path... This could be solved with https://github.com/QubesOS/qubes-issues/issues/5853, but that exists only in plans now. > # Implementation details > > The circumstances lead us to consider the implementation of an alternative > security mechanism, proposed here. (...) I think it looks ok. Regarding one-time access, I'd rather specify it with a timeout, to avoid cases when the client VM requests authorization but uses it much later. One thing you may want to consider is interaction with GUI domain - in this case dom0 couldn't directly ask the user, but rather ask the GUI domain to display the prompt. We do this for normal policy prompts. Anyway, it's of course up to you whether you support GUI domain or not... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG4qfIACgkQ24/THMrX 1yy3Ywf7BE7xOcqzMdSgn4Un3SZkokDMBaoN0Rr2EQ5pNLPgM9SUI9NEnvJ+TEZ7 xLTvNpRiYWSkjmVXsfUJrCZmQ+0NEvifiay4xWP0g/paYfRaL9Pa2vMOtHMv2Ncv vcE0T01bCrek/0BPJfsQI1n27zaZdUwIz4o3sJofzRoocMBk7Kq0x6jC/Gw35Qkh xi42R7XcDutPwuRi5JZKTBxfH7hVIKkizEIEUsN7qe0Fn80nfhRvdIi6VgJb+Wz2 3cJ38oiMBQg46OQ256J1viMZaKz+H4hyDWtTJcCzLcu9mImr+tkdIVHTFrBNMjbF QRmSGRsAV3LuScjUGCTIYDAV3A6qmA== =OcxO -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/Ybip8vY29iVo3cY4%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 08:00:37PM +, Zrubi wrote: > On 11/17/21 19:48, Marek Marczykowski-Górecki wrote: > > > > the folder name has a typo: > > > qubes-udates-proxy vs. qubes-updates-proxy > > > > > creating the correct directory fix the issue. > > > Now the question is who (or what process) creating that wrongly? > > > > You, when adding it to qvm-service :P > > Ahhh. > > a 'nice' debug session to find my own typo. :| > > And the empty service list in the GUI is the expected behavior? - would > have saved the world from this thread ;) Theoretically there should be a drop-down list with known-supported services, but _this_ seems to be broken for disposable qubes... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVZ9YACgkQ24/THMrX 1yyUGgf+KGfv/Mp+0en1/igOQ9EDG41qEuHph7dCBujByowDs4ATM5QQK8MBSpL4 67t6ZNBj5xA71FugWeiS9EQqz6zkJ9s1ntPfcCMaqMQspueSUQ6zoal6MHldSDBv VOrtOBeNCjJGOkOibgDGEL4DqlxFlxsdExTzVnUwp2TghEeLYCa6ywvDhtcIwfDk /HJj/aFMGualkEkr+6/ldjwJBh7NihLFSL0cQGNKlYUjhWzo49+3AS+42bxxWWCR DH6pG+sb2m3pYi79ieM5rNWwycdfI3LCIuGCplHJA0DQBKzDhinRsPO5xWwZE2Pw TZo1AN7owpqul0IdPHmIdN8e7hlM5w== =ELIn -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/YZVn1odZuHY6R09D%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 07:37:28PM +, Zrubi wrote: > On 11/17/21 19:27, Marek Marczykowski-Górecki wrote: > > > Try `systemctl status qubes-updates-proxy` there. > > user@sys-firewall ~]$ sudo systemctl status qubes-updates-proxy > ○ qubes-updates-proxy.service - Qubes updates proxy (tinyproxy) > Loaded: loaded (/usr/lib/systemd/system/qubes-updates-proxy.service; > enabled; vendor preset: enabled) > Active: inactive (dead) > Condition: start condition failed at Wed 2021-11-17 18:49:19 GMT; 43min > ago > └─ > ConditionPathExists=|/var/run/qubes-service/qubes-updates-proxy was not met > > Nov 17 18:49:19 sys-firewall systemd[1]: Condition check resulted in Qubes > updates proxy (tinyproxy) being skipped. > > and the reason is: > -rw-r--r-- 1 root root 0 Nov 17 18:49 > /var/run/qubes-service/qubes-udates-proxy > > the folder name has a typo: > qubes-udates-proxy vs. qubes-updates-proxy > > creating the correct directory fix the issue. > Now the question is who (or what process) creating that wrongly? You, when adding it to qvm-service :P - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVXIkACgkQ24/THMrX 1yyUKQf+LVoqTHUA/yZl9+7MM2bIiX9glVu5IZcZecNMRqHGrVoMmieEoQm1qDSQ 3SY36G9JhyePJCd4yyc5nL9cFTtlFp8jhOxsgJtBGJXeXG0EBDQY4+XSb+mQ38iz M6d3/2UnkGJdZ84gU0bCcNeWSvkur6UXx/vuotkWosD98j31yv4z2gzMcQc7na+R u7xVdVfHma96Q9j+df89zG8DcOrJQEWDonbmqkHiGjpuAraXtF+SZ8fXpNlNYiAI h4VdTp+eZSiHXiJr+fa66xr60viAM3IDPt4jONycZmY6UtAOKOejVIlzFkdu/syl 9qNda1RWSGIUgIaqPjJaqB8F6bU3Wg== =D1E9 -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/YZVciqrrouWmVwe0%40mail-itl.
Re: [qubes-devel] qubes-updates-proxy in dvm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 07:25:23PM +, Zrubi wrote: > On 11/17/21 19:14, Laszlo Zrubecz wrote: > > > unfortunately I don't have any working example any more, so I have to > > create a new vm to see how it is working in a normal VM... > > > > But as I remember for sure, the tinyproxy service should listen on port > > 8082, what I can't see in my case. > > > > I can confirm, in a normal Appvm (whic provides networks for others) working > as expected. > (using the 'factory default' fedora-34 template) > > I see the qubes-updates-proxy.service, and it is listening on the expected > port. > > In case of a factory default sys-firewall, I just can't reach this state - > even the GUI and the CLI show the service enabled, it is not even shows up > by > `systemctl list-units` > > Any advice what to check? Try `systemctl status qubes-updates-proxy` there. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVV74ACgkQ24/THMrX 1yyGQAf/ezHPLDzuJiAkvCQTGLTvxidUKQuEbHFTsQIPopcx1iY9KPRpHQbmG9jt b1lx/HK3A9e6mvU5zuCEH72xBOs9HhUpCeH59opfG2edNX6rik9LEnx5vAVdeHrJ hJKL4rsDnsq6aoJX6Y/9rk3UoHg+5MDmsNbXoOV8aUL3BKw40ApuyHJ7Ki1TykVY LxOLYH3IPbdb+mfFCEbkYdD9HkveN5+CvL5BR0th80/lgxyyNr11YTjHCcNTI/nb ZeYrE0sdIxgDoU63h/OLbPA/OyRWI6/zv3hQYqhvx0Z+Etleu/RNsdc7ZqMfEEcu agJsLXRl1ZtqxVNUKBIJYD0e0yxaNQ== =8ifb -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/YZVXvoB0oizD%2BRmC%40mail-itl.
Re: [qubes-devel] sys-net hardcoded as a default net-vm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 06:40:01PM +, Zrubi wrote: > On 11/17/21 18:19, Marek Marczykowski-Górecki wrote: > > On Wed, Nov 17, 2021 at 05:05:01PM +, Zrubi wrote: > > > > user@dom0 ~]$ sudo grep sys-net /etc/libvirt/libxl/sys-firewall.xml > > > > > > > > This seems like a hidden property, as not show on the GUI, but not even > > > using qvm-prefs. > > > > It is in qvm-prefs very explicitly: a netvm property of sys-firewall. > > Hmm, then it was just not is sync for some reason: > > name- sys-firewall > netvm - WiFi > > But now the .xml and the output of the qvm-prefs are in sync, so not sure > how it happened - maybe I just missed something. Sorry for the lame question > then :) The libvirt xml is updated at VM startup. So, maybe you haven't started sys-firewall after the change yet? > > > user@dom0 ~]$ grep sys-net /etc/qubes/policy.d/90-default.policy > > > # Default rule for all TemplateVMs - direct the connection to sys-net > > > qubes.UpdatesProxy * @type:TemplateVM@defaultallow > > > target=sys-net > > > > > ^^ Maybe this is triggering it? > > > > This is what templates will use to download updates from, see > > https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy > > So, yes, if you want to use something else, you do need to change it > > (but I recommend creating a new file with lower number and putting your > > rule there - it will take precedence over later rules). > > Yeah, I was found it meanwhile... > And thanks for the advice, makes sense to not mess up the default :) > > > So my 'issue' just shifted to have a qubes-updates-proxy process somewhere > else than sys-net. > > Previously I was running it in my sys-firewall. > Now it is a DVM by default, and I can't find the way how to run the > qubes-update-proxy in this case. It should work the same way, just enable `qubes-updates-proxy` service on the sys-firewall (via qvm-service). While the data inside won't persist (it is a disposable VM after all), its settings will persist. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVTbMACgkQ24/THMrX 1yx+7wf9EetCr5FIvl7jazUMvGBS3Rss8HIj3xCgO4X8Wl2iEesm8fIFbM3h+nsy 5kdNgqFKRX8juoFFH/a16Pl54Uvke7Zad0fJ3IJ2GQsKImCFIObGByYNNvs1sFo7 /qniVOh8K0bzJUcTaFN1SlvHSc0r2Bd1c9Zjye/KM0wHe2ktdAI75bdqApxW1OPq WNWj6QQ+MhOQ5sA4TeciPza561OLwD5uplZmH/2HiGGfLet+e0nwVCMr0s4Nl1+H 4eIBwl10qidcqJ1jQFfiNA+nh2Aercoa+3TYCyfWLvGNgvifdzqc47MDBUqcDX1h aGkz5fnRxOv3Rg3m9yosS/23P+l5Yw== =Guo3 -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/YZVNs/gjZXqDXIdk%40mail-itl.
Re: [qubes-devel] sys-net hardcoded as a default net-vm
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Nov 17, 2021 at 05:05:01PM +, Zrubi wrote: > Hi, > > I just upgraded to 4.1 which is went fine using the backup and restore > procedure. > > I have found out that the 'sys-net' as a default netvm is hardcoded in some > places. > > Why it is an issue? > becuse I using another netvm (separate WiFi, and Ethernet VMs) by default. > > > I have already changed the default netvm, not any single VM are using the > 'factory defaulf' sys-net any more, but still the template upgrade process > pull this in somehow... > Ending up without net access because of this. > > I have found two reference so far: > > user@dom0 ~]$ sudo grep sys-net /etc/libvirt/libxl/sys-firewall.xml > > > This seems like a hidden property, as not show on the GUI, but not even > using qvm-prefs. It is in qvm-prefs very explicitly: a netvm property of sys-firewall. > user@dom0 ~]$ grep sys-net /etc/qubes/policy.d/90-default.policy > # Default rule for all TemplateVMs - direct the connection to sys-net > qubes.UpdatesProxy * @type:TemplateVM@defaultallow > target=sys-net > > ^^ Maybe this is triggering it? This is what templates will use to download updates from, see https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy So, yes, if you want to use something else, you do need to change it (but I recommend creating a new file with lower number and putting your rule there - it will take precedence over later rules). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmGVR6MACgkQ24/THMrX 1yzFWgf9F7u73O1UjzaeQOcB3if85slbkJg/VI4C3te19wx6Ou+IJKp1XgjyN8rZ 23voRMqSjgMcN2+FFuD9jS7QbvnzkKPZcmYoMlhOXDJDDqcETMxWhP+uTH/F28UH uM1VValvTSJToCdckbrltgdMkv2Miux+1+1ZhfRxGYP+ZH5HEgM0LoKag7wltfrO yysB/TsP9NHUwQPzSw4O/KejmfLeZefbNGmv/RZLcs3rkYeYakRGs1o4DgCGGttT JZG43LqWr0X3LrUeFCLmbfVoiSFr2v7NTY7wamGVvEn9o7WpeJkGgRHdyKk6cbGy RSt6WoI6B+XLjvxi6QDEoUwZ/yjxQA== =ukvE -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/YZVHpHYhaNck5nNs%40mail-itl.
[qubes-devel] Hosting for OpenQA instance (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, It seems our current hosting for openqa.qubes-os.org is no longer a stable option (thanks to the anonymous supported who provided it for the last two years!). Also, the current number of the tests we run makes our current setup barely sufficient. So, we are looking for a new/additional machine to run openqa on: Does anyone have some place/recommendation where to look? Hardware we need: - CPU with VT-x + EPT, so KVM will work with reasonable performance (this means a physical machine, not virtual one) - 8+ GB RAM (6GB for KVM + something for OpenQA itself), preferably 32 GB or more - 500 GB of disk space (preferably more) - fast internet connection, preferably in European location - peak traffic about 200 Mbps, in short bursts (transferring disk images for tests) Does anyone have a spare machine running somewhere, and willing to share? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFuxJwACgkQ24/THMrX 1yyCawgAgDWRPueH/smmNRngYN3mPIHYxhQmvPhUElRl/JR4pYAk9l4btibOZ/4R LwCXppeaTZaa9rIl6wG6peFiEfVd+UkUQQAtOHPnRLR6hdwBoUGueC0d6q2zOqw+ AbZTCSowASkQJLoGiiqdFggVLzhhZnPbOu4HZOByxZ3PzcRUgflzk6lr+SzARI+o bDYze1oTXIuJVIx4sWnnBuNe9iVt8owuG4KliU9E/H4HhIO1uNqCoIcbvluqEMBn z5SoOVSg96ZVIHuCFc2eUQETv6CaBThEPyRvcUu38c/cvx5R0LDrlyxksXa1x564 bBft8ZncDWNHrkQbMwS2BGkF6uzKSQ== =y3br -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/YW7Em2W0xGS03xzU%40mail-itl.
[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 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) - unsupported data transfer mode (should be better now, since the current USBIP driver has XHCI support) > > > 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). 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. An alternative, is to use socket service. If you don't like an extra process laying around, you can use socket systemd unit, with Accept=true if necessary. But then, you need to read the service call handshake before using it for the actual data (not a big deal). > with > checks that the message actually came from the correct child process. No, that's a bad idea. This forces specific process structure of a service, which will be limiting factor. > > > 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). > > T
[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 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. > 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... > 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). > 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. > > > 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. > 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. That's true. In fact it's yet another case, where overriding the call argument at the policy level could be useful (something I consider adding for a long time already) - then you could have different sockets for different users. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFkSfAACgkQ24/THMrX 1ywmewf8CMW2/gkqaS9HUjCmbtzPorNJaeCH12fWsgj1eiA9AY85s4aesF0a74Nr VZOzven0UANGKaVD3ZH77uTi+0h8Wu57QAOvclKzQqTES5MrOdC0WKKqjjGV6WYP Mf1P0w/828/DPcsKt13Og8OchbuFTLX46ricv3W6awyPkd4e3MyJIIP+J/x3qRUd TSvy6/kci4q3YOqUSUu9FjA2
[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 03:26:11AM +0200, Simon Gaiser wrote: > Marek Marczykowski-Górecki: > > 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. > > But in that case split-gpg2 would open one unix socket and accept > connections there. So the above mechanism wouldn't be needed at all, or > do I miss something? Indeed, switching wouldn't be needed in that case. Using a single FD for both reading and writing would be. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFfogMACgkQ24/THMrX 1yzNvwf/blB33gjzEASn2O8tQVyNX+pU2qzHntidNjacL2InsfB+P7ls7eCozK4l m/sgeujhJHY+n3BpHdoM/U8v6Man5/a080DpSDIFoxG/2GYAvLNZUS4u3yb2afJ8 Nahnv2MdrigWTNm6buhFS+LK0UjF6nIetGOzk9hOFdJi6AZxV8LG18LuvJUtJlue Q0gmmtFnfsd5YbMuYnHSSYWO0AoXfJcnrnryCgHC21ciAHdUhep2GPiIgwe+Jxd6 pcMoBPH36nvPYsZo721Rx/3yEG2Mb5Nz8ychHWIh5LixuqqmkAwTKqhuHJOHqIQ8 fauFvbEGBpSElgGy5ll2NdY3reqHaA== =/2wR -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/YV%2BiBC%2BGndpvZ1Et%40mail-itl.
[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: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? > 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. > Simon > > [1]: > https://github.com/QubesOS/qubes-core-agent-linux/commit/c1cb78e0e8e2e6090c32e2c1cddc9f8bcbd8399e > [2]: > https://github.com/QubesOS/qubes-core-qrexec/blob/339f79a13403ce240e4e0748717d8fb9674b31b3/agent/qrexec-agent-data.c#L215 > [3]: https://github.com/HW42/qubes-app-linux-split-gpg2 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFfjyYACgkQ24/THMrX 1ywkiQf/VQ4pt40jsf/5YTn9OW9hTrfkh7ykMqo+X2Te0VKEuopu8XeBsvyZK1Hv /Up+clWj5RnCI+33jrV4wK56ddRBPiogenyrbBrel36hP0AXBHtljU4lIFmOu388 HbnOo4OQiaTK1ZuHMxaC2t56mThgCCrlarlvw020uzrTncI0nNvgdLmWZf0bgCJX SEgsWpBNzEOdAXia0uY19l0jXM4EvFEEbaE7EaaXqfXyY7D+qtuF9HSNMid58fyN 3FhvtuwHcTBgD2/Vdd9GeU93quCdXtc/H0E7zL0XO8HP/2V0eMkzGG2oWvc5Klrd q747t9tYoKqfgYQj1SvLU4y0Wa1ddg== =7TGX -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/YV%2BPJlBK%2BkJg%2B/Jv%40mail-itl.
Re: [qubes-devel] Re: Should we migrate the documentation to another platform?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Sep 28, 2021 at 06:06:41PM +, Tobias Killer wrote: > Hello, > > one feature that is often used in Qubes Doc is the automatic generation of > HTML IDs like, for example, if the source Markdown file contains > > ``` > # Hello world > ``` > > the resulting HTML file contains > > ``` > Hello world > ``` > > which means one can link to that heading via `[Link](#hello-world)`. > > Are there pendants in RTD and Wiki? In what way? RTD does that automatically, for example: https://dev.qubes-os.org/projects/core-admin/en/latest/qubes-events.html#handling-events-with-variable-signature But that's for rST input, I'm not sure if the same will work with MD input (likely yes). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmFTXgQACgkQ24/THMrX 1yx0xggAir2EbXJT0wEfTtCYy7aT8nhSYl8tjjF2dr2gXaC51C0GZLX7+XZiUxec 5HNFoo6TTFs+51ykmsVjDuuIAa2ekmVKbyty8Kl9FXzXkWtJG774oY6UCfNM+JCd n8jZ5MjzQv6h3adfQP6QcBayPoFnzjwzKilnwsK7c1aMsNkku/jIm8nJ3zkV6omH h/goLMesX6H20SOjLKKsLkiHIg+p01uG6rLJDnxELBNE33Sy/rSC323hDihmr/6K wnWJR2SElqlqpptTa8vyHi41KpVODKBJ7R0SxTKVY4d7y5TJOKyrBbbD98R/uJWm YNTXpHyVCzfEJQ5PQgVRt6VR/+YROw== =Te7J -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/YVNeBGASP5WGKPJQ%40mail-itl.
[qubes-devel] QSB-071: Fatal options filtering flaw in Split GPG
Dear Qubes Community, We have just published Qubes Security Bulletin (QSB) 071: Fatal options filtering flaw in Split GPG. The text of this QSB is reproduced below. This QSB and its accompanying signatures will always be available in the Qubes Security Pack (qubes-secpack). View QSB-071 in the qubes-secpack: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-071-2021.txt Learn about the qubes-secpack, including how to obtain, verify, and read it: https://www.qubes-os.org/security/pack/ View all past QSBs: https://www.qubes-os.org/security/bulletins/ ``` ---===[ Qubes Security Bulletin 071 ]===--- 2021-09-09 Fatal options filtering flaw in Split GPG User action required - Users must install the following specific packages in order to address the issues discussed in this bulletin: For Qubes 4.0, in templates and standalones: - qubes-gpg-split 2.0.53 For Qubes 4.1, in templates and standalones: - qubes-gpg-split 2.0.53 Due to the ease with which this flaw can be exploited, we are immediately migrating these packages to the current (stable) repository, bypassing the usual testing period. These packages are to be installed via the Qubes Update tool or its command-line equivalents. [1] Summary Split GPG [2] is designed to isolate private keys from the application using them in order to protect them from being extracted and to allow the user to retain control over when they are used. This isolation is implemented by forwarding calls to `gpg` into a backend qube that holds the private keys and allowing only specific `gpg` options. This option filtering mechanism rejects options like `--export-secret-keys` and others that might leak private keys to the frontend qube. Unfortunately, several options were declared incorrectly, which allowed this filtering mechanism to be bypassed. Impact --- An attacker controlling a frontend qube (where `qubes-gpg-client` is executed) can extract an arbitrary file (including a secret key) from the backend qube. Discussion --- Several `gpg` options were declared incorrectly in Split GPG, which resulted in Split GPG interpreting them differently than `gpg`. If Split GPG interpreted one option as an argument to another option, Split GPG would allow it, since option filtering is performed at the level of the options themselves, not their arguments. This would allow options misinterpreted as arguments to bypass the filtering mechanism. Specifically: - All `--s2k-*` options were declared as not taking arguments when in fact they do take arguments. - `--export-ssh-key` was declared as taking an argument when it doesn't take one directly; it does change the meanings of positional arguments, however. - `--with-colons` was aliased with `-k`, which differs in its argument requirements. - `--default-recipient`, which takes an argument, was interpreted as `--default-recipient-self`, which does not take an argument. - `--display` was interpreted as `--display-charset`, which resulted in `--display` being allowed when it should have been denied. For our immediate, initial response, we have corrected all of these inconsistencies and added automated testing to verify that GnuPG and Split GPG both understand the options in the same way. More generally, we will prioritize finishing Split GPG 2 [3], which does not rely on option filtering at all. Instead, it uses `gpg-agent`'s protocol to delegate only secret key processing to the backend qube. In addition to obviating the need for fragile option filtering, this dramatically reduces the attack surface, as most of the untrusted data processing is done in the frontend qube and never reaches the backend qube. Credits This issue was discovered by Demi Marie Obenour. References --- [1] https://www.qubes-os.org/doc/updating-qubes-os/ [2] https://www.qubes-os.org/doc/split-gpg/ [3] https://github.com/QubesOS/qubes-issues/issues/474 -- The Qubes Security Team https://www.qubes-os.org/security/ ``` This announcement is also available on the Qubes website: https://www.qubes-os.org/news/2021/09/09/qsb-071/ -- 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/YTqHZEE4pC0MGCr1%40mail-itl. signature.asc Description: PGP signature
Re: [qubes-devel] Re: build system does not build, libvirt ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Thu, Sep 02, 2021 at 06:01:56AM -0700, ludwig...@gmail.com wrote:
> Here is my builder.conf
This is a config for building Qubes 4.1, not Qubes 4.0. Take a look at
example-configs directory.
Furthermore, I'd recommend keeping DIST_DOM0 unchanged (fc32 for R4.0).
Even if it will succeed to build (which is not that obvious), you
wouldn't receive updates if you build for a different base distro.
As for the build error:
> > sudo BACKEND_VMM=xen chroot
> > /home/build/src/qubes-builder/chroot-dom0-fc33 su -c 'rpmspec -P --define
> > "debug_package %{nil}" --define "fedora 33" --define "dist .fc33" --define
> > "fedora 33" --define "dist .fc33"
> > /home/user/qubes-src/core-libvirt/libvirt.spec >
> > /home/user/qubes-src/core-libvirt/libvirt.spec.parsed' - user
> > cat: version: No such file or directory
> > error: line 275: Empty tag: Version:
... you found a bug.
Fixed here:
https://github.com/QubesOS/qubes-builder-rpm/commit/00bea13e220497efc288ffa14019dda579257723
Execute `make get-sources` again, and retry.
> > Also is there a vm image of a proven good qubes-buidl system, as the build
> > system
> > is very sensitive to moon phase and moisture :-)
Yeah, that is a bit tricky indeed. But a VM image would hide issues we
should fix anyway...
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmEw4mMACgkQ24/THMrX
1yxcHwgAliHkGnK2HoE/Y65DFVw5z5MpCWVyz7d19QQ4YAwMcsKqG7EHm8fGAg7n
45g+HDJx2DhpyFAHEYI1UIsrziGIxCbi3Y5slcFr8FpwyYiz+pDay42ywVPhQhh1
amY4y6MX6Z0oKxgdf1mbnOMaw0oSovzlrgnz7FY4+hcAxsTRweIMTKm+r7WFgmMt
NGMltxYieIEtrDeAqjbHX9fzgXuoPgGSAizekVzBUV6hX/dX5VToH/yOmNNn3kA/
aD+b73YVFGruYFuY9ZkuKYll5CT/2/zJN+bxDcGWdQkx/yrxxo0DL27maoS56uDi
8EhIjsOdY7MV1tZ56ebmwG54Gn5FFg==
=WWUc
-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/YTDiZE7PL0Q8Xtz3%40mail-itl.
