[qubes-devel] Re: Port Forward using iptables broken?
On Saturday, 10 February 2018 00:13:00 UTC, joev...@gmail.com wrote: > On Friday, 9 February 2018 19:02:09 UTC-5, Alex Dubois wrote: > > On Friday, 9 February 2018 23:59:52 UTC, Alex Dubois wrote: > > > On Friday, 9 February 2018 16:36:14 UTC, joev...@gmail.com wrote: > > > > Yes, thanks for pointing out the typos. They are only mistakes in this > > > > post. I use a script running in dom0 to generate pretty much > > > > everything. The same script works when debian-8 is used. The > > > > interface is different depending on the template > > > > > > I confirm I have the same issue. > > > Please however note that I have another PCI NIC connected to an AppVM (My > > > qubes also act as a firewall for home network) and we have no issue > > > connecting outbound. > > > Outbound connection as you know do not need the PRE-ROUTING rules, so > > > also the problem is seen on the FORWARD rule, I suspect more the > > > PRE-ROUTING rule is at fault and does not do its job. > > > I'll try to dig into this, however I won't have much time this week... > > > > Also, could you clarify if you've tested on FirewallVM and if here again > > Debian is OK and Fedora not. This might rule out issues with physical cards > > (which I suspect is not the problem as PRE-ROUTING does get the packet). > > Yes, if the template on sys-net is changed to Debian-8, but sys-firewall > (FirewallVM) is left with fedora... sys-net does send the packet to > sys-firewall, which then appears the same way... PREROUTING sees it, but > FORWARD does not. > > Thanks. > > P.S. > Debian-9 has issues as well, but I didn't test thoroughly with that. And I > think Fedora-25 was working prior to some updates. I do enable testing repos > for these templates, but don't know what package is the culprit and don't > know how to rollback. I have opened a thread on the iptables mailing-list to try to go to the bottom of the reason why it stopped working with subject: iptables PREROUTING to-destination hit but no hit in FORWARD (advanced) -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/dd68eef8-f14a-40a3-8d3f-e780e16cc707%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Marek Marczykowski-Górecki: > On Fri, Feb 23, 2018 at 03:27:38PM -0700, Reg Tiangha wrote: >> I've noticed that Xen has updated the XSA-254 advisory with Spectre v2 >> mitigations for Xen 4.6-4.10. I know we'd have to figure out how to >> backport Retpoline compatible compilers to these various build >> environments in order to get the full protection (Debian has backported >> that support to the gcc versions in jessie and stretch so that implies >> that at least the backported gcc patches are now available), but is >> there any chance that these Xen patches will be incorporated into the >> Qubes versions soon? > >> https://xenbits.xen.org/xsa/advisory-254.html > > Simon, can you take a look at it? We'll probably need to put patched gcc > to linux-dom0-updates repository (if newer Fedora has patched gcc and > it's possible to build that src.rpm on older Fedora), or add separate > repository with patched gcc - then probably indeed based on patches from > Debian. It seems to be working for me, but the gcc part is a bit tricky. Building a newer gcc src.rpm doesn't sounds like a good idea since the package contains a lot of stuff which probably breaks on a version jump (like libgcc, libstdc++, libasan, ...). My original plan (i.e. before the XSA got updated) was to build an extra gcc just for vmm-xen (and probably linux-kernel). But now I noticed that Debian published backports for gcc-6 and gcc-5, so R3.2 is also covered. So I decided to add those backports to the Fedora gcc package. I got this working now, but it has some caveats: - The Fedora gcc package build seems to be flacky. It failed twice for me with different errors (both verry likely unrelated to the backport patches). Assigning a lot of memory to the build VM got it working ... And I noticed that a bunch of tests are failing but apparently that's not a reason to break the package build ... - Installing the patched gcc required manual intervention in my chroot (didn't tried a fresh chroot yet). For some reasons it only wanted to install it when I told dnf explicitly to install the updated gcc and libgcc. Then dnf was happy (i.e. no more error about dependency problems) - Updating gcc is "all or nothing". So should the (probably unlikely) case occure that the new gcc cases problems with other packages we can't keep using it for vmm-xen but not for other components. Other options: Build an extra package with a current gcc (i.e. 7.3.0). This package would be much smaller (since only C support is needed), so debugging build problems is much easier (if they happen at all). We can switch on a per package base if we want to use the patched gcc (CC=gcc-7). Since this was my plan before knowing about the backports I already done some of the work for this (one search patch issue is not resolved yet). The downside is that the version jump (gcc-6 (or gcc-5 in R3.2) to gcc-7) might create problems with vmm-xen and linux-kernel. Build an extra package with the gcc version as used by Fedora (as above C only). This would avoid the gcc version jump, but it might be trickier to get two variants of gcc with the same version to co-install without path conflicts. What do you think? My current state (variant 1 (i.e. patch main gcc package)): https://github.com/HW42/qubes-vmm-xen/tree/hw42/sp2 https://github.com/HW42/qubes-gcc -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAlqTIkkACgkQkO9xfO/x ly8aLhAAyUFDvZEpScH8zgYa5sO+1tRrB1YGlsRkcSyUtodcGqEBRL6ZOc0Vwuu9 oKOabryweo+By7AAnehFXdAv5aaI6BZ7pWZs9EPcvCJIphQiX8KSIyzQFRkfg8LL uIBdH60udqsZGZIsZ3vr9hDFxvM2mIeeF9rNJhahvSYHUl438eOmAMEglVTKuU0R OB2ffmtluatXlZdoAapY7+uAkkGCvVpS6zg87y0iWUVGC/EoPxQyrY3qn5uRGeKa 3iB7xb5Hf1THsj4NuDIWHGf2xLWYLkg/N8LoAJG4X8HUGvISlbollA+h0Qw3v/5C EtvvIInTGYkBo8+LXdAka7U3AjUpkGVbYRqNaoB1Si0iCFbCN13jTXT2AUnkRfWd vSbNV3qramZr+TRK75K+b4+M7SxdEFDDc8vjBt3K1WGWwRDl14hxN8Sjh4pyjE8Y ORLt2bQ4COkIaVZutenpRRxWIkuQY4CHvdPGiXTd50i5C0fk8E0fbiYUYndlSUHO f+gmeIaXcOfDnobeUpVOE9kdpqrapqSvsVWYzKnkw94/xMkJCH20V5f0PdJO5iTK nFUqjLua9MP4NyU+QOfYgyaoq8AcU4diUeAh8j1BQ+j6wzPF8VYmgCevpUJihTnD 0nUoBhfspxUsmvMPq2Nb5t8rUXGlisRx6xLvCnikvUSjcZuuZbQ= =IWk8 -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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/4624db81-9521-812a-88be-8e16b25ac297%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: Port Forward using iptables broken?
On Saturday, 10 February 2018 21:45:30 UTC, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Feb 09, 2018 at 04:12:57PM -0800, joev...@gmail.com wrote: > > On Friday, 9 February 2018 19:02:09 UTC-5, Alex Dubois wrote: > > > On Friday, 9 February 2018 23:59:52 UTC, Alex Dubois wrote: > > > > On Friday, 9 February 2018 16:36:14 UTC, joev...@gmail.com wrote: > > > > > Yes, thanks for pointing out the typos. They are only mistakes in > > > > > this post. I use a script running in dom0 to generate pretty much > > > > > everything. The same script works when debian-8 is used. The > > > > > interface is different depending on the template > > > > > > > > I confirm I have the same issue. > > > > Please however note that I have another PCI NIC connected to an AppVM > > > > (My qubes also act as a firewall for home network) and we have no issue > > > > connecting outbound. > > > > Outbound connection as you know do not need the PRE-ROUTING rules, so > > > > also the problem is seen on the FORWARD rule, I suspect more the > > > > PRE-ROUTING rule is at fault and does not do its job. > > > > I'll try to dig into this, however I won't have much time this week... > > > > > > Also, could you clarify if you've tested on FirewallVM and if here again > > > Debian is OK and Fedora not. This might rule out issues with physical > > > cards (which I suspect is not the problem as PRE-ROUTING does get the > > > packet). > > > > Yes, if the template on sys-net is changed to Debian-8, but sys-firewall > > (FirewallVM) is left with fedora... sys-net does send the packet to > > sys-firewall, which then appears the same way... PREROUTING sees it, but > > FORWARD does not. > > An idea: Debian don't have nftables installed by default, so > qubes-firewal fallback to iptables. But not on Fedora - there nftables > is used. This applies to both sys-net and sys-firewall. > > A quick test: > > 1. List rules: > > nft list table ip qubes-firewall > > 2. Add rule accepting traffic from eth0: > > nft add rule ip qubes-firewall forward meta iifname eth0 accept Shall I test and document firewall.md all using nft if it all works (there are some incompatibility warning in the nftables wiki with iptables for nat that may need us to move fully to nft)? I'll be happy to try (in my spare time and own pace) to submit PR for all the qubes firewall scripts in sys-net and sys-firewall if you think it is the right way forward. > > - -- > Best Regards, > Marek Marczykowski-Górecki > Invisible Things Lab > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > -BEGIN PGP SIGNATURE- > > iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlp+rHcACgkQ24/THMrX > 1ywR9gf/RJFy4TVihhweEh7ZqpwKTTD/JNgYCrl2nelvRwxl8awlqL/sxBBTGo39 > byprAaL/Oe+6L4aX3d/tfbmpuJ7plHIJvm9PIxQ4SVj46iEcMRJIm1xQCjV8YtFu > bvAna5vrisuUuaEo/Kx1a7ee4gJTjHNUtTgA8N2ar+oL/csG2Vlz38zCVjAD8isf > HoCn8H35V4zvJoVXNuFTpSBplIlxa4ouryBWT9GQktBnZ1OPqdeiKotgFX2N5sJc > z01XQQ83HWJ+1/x+iGI9OoGidBKHI+izjSNhlyO70SW/9L1Xg+2NkaetJcO1VLHI > TaegOvEhZkvw2X6DVeeG5fGk1nYKXQ== > =evy9 > -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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f217a6dc-1933-40fc-bd2e-3091de7d19e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: qubes-url-redirector v2.1 released!
Version 2.1 is not working on my Chrome 66.0.3350.0 (Official Build) dev (64-bit) It blocks URLs properly. It allows those matching the whitelist properly. But nothing is run on the Default VM specified. Also, I still need to add polyfill.js to the package prior to Chrome accepting the unpacked extension. The commenting out in the manifest.json doesn't work. https://github.com/raffaeleflorio/qubes-url-redirector/blob/master/chrome/manifest.json#L41 -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/38a73b33-31fb-4bc2-a2ba-7d42a8bd7755%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] qubes-url-redirector v2.1 released!
On 22 February 2018 at 15:52, Jean-Philippe Ouellet wrote: > > One possible solution would be to add a new type of Qubes RPC rule: > present > > the user with the most recently opened DispVM to use as a default (that > they > > can change before clicking OK). It might look something like this: > > > > /etc/qubes-rpc/policy/qubes.OpenURL: > > > > $anyvm $dispvm ask,reuse > > > > (I think this idea needs a bit more thought!) > > As to point 4 and the implementation of VM re-use, nothing additional > is necessary from the current qubes-rpc plumbing. > > Returning a name would be undesirable since the source VM should not > be able to specify a specific destination VM (indeed, ideally might > not even know the names of any other VMs on the system). Increasing > complexity of the policy evaluation logic is also undesirable, since > this should ideally be kept as simple as possible. > > A solution today might include a service like: > $ cat url-redirector.RemoteOpenSession > #!/bin/sh > > while read -r url; do > case "$url" in > http://*|\ > https://*|\ > ftp://*) > qubes-open "$url" > ;; > *) > echo "Invalid URL" >&2 > ;; > esac > done > > and be invoked from another VM with: > $ qrexec-client-vm '' url-redirector.RemoteOpenSession > > This allows the source VM to keep a handle to an anonymous destination > VM to open arbitrary links in the future, without any cooperation or > changes in dom0 or policy evaluation or anything. > This all looks sensible to me. Thanks for thinking about it! Cheers, Andrew -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAAXZBWJAnDqdwMQ9tecqO_y_B2x5KMNEU9bUgvcpg4d8Vm78CA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Feb 25, 2018 at 08:53:00PM +, Simon Gaiser wrote: > Marek Marczykowski-Górecki: > > On Fri, Feb 23, 2018 at 03:27:38PM -0700, Reg Tiangha wrote: > >> I've noticed that Xen has updated the XSA-254 advisory with Spectre v2 > >> mitigations for Xen 4.6-4.10. I know we'd have to figure out how to > >> backport Retpoline compatible compilers to these various build > >> environments in order to get the full protection (Debian has backported > >> that support to the gcc versions in jessie and stretch so that implies > >> that at least the backported gcc patches are now available), but is > >> there any chance that these Xen patches will be incorporated into the > >> Qubes versions soon? > > > >> https://xenbits.xen.org/xsa/advisory-254.html > > > > Simon, can you take a look at it? We'll probably need to put patched gcc > > to linux-dom0-updates repository (if newer Fedora has patched gcc and > > it's possible to build that src.rpm on older Fedora), or add separate > > repository with patched gcc - then probably indeed based on patches from > > Debian. > > It seems to be working for me, but the gcc part is a bit tricky. > > Building a newer gcc src.rpm doesn't sounds like a good idea since the > package contains a lot of stuff which probably breaks on a version jump > (like libgcc, libstdc++, libasan, ...). > > My original plan (i.e. before the XSA got updated) was to build an extra > gcc just for vmm-xen (and probably linux-kernel). But now I noticed that > Debian published backports for gcc-6 and gcc-5, so R3.2 is also covered. > So I decided to add those backports to the Fedora gcc package. I got > this working now, but it has some caveats: > > - The Fedora gcc package build seems to be flacky. It failed twice for >me with different errors (both verry likely unrelated to the backport >patches). Assigning a lot of memory to the build VM got it working >... And I noticed that a bunch of tests are failing but apparently >that's not a reason to break the package build ... That's a little worrying. Fortunately in practice (I hope) we need to do that only once (thanks to fc23 and fc25 being EOL). Have you tried building it on Travis-CI? That could be also a way to stress-test this build. > - Installing the patched gcc required manual intervention in my chroot >(didn't tried a fresh chroot yet). For some reasons it only wanted to >install it when I told dnf explicitly to install the updated gcc and >libgcc. Then dnf was happy (i.e. no more error about dependency >problems) That's strange. Are you sure the version is greater? Is dnf reporting this as an update? > - Updating gcc is "all or nothing". So should the (probably unlikely) >case occure that the new gcc cases problems with other packages we >can't keep using it for vmm-xen but not for other components. Actually, if we _really_ want, we can. I can setup separate qubes-builder instance (with separate chroots etc) just for vmm-xen. But that would be cumbersome, and IMO very unlikely needed. > Other options: > > Build an extra package with a current gcc (i.e. 7.3.0). This package > would be much smaller (since only C support is needed), so debugging > build problems is much easier (if they happen at all). We can switch on > a per package base if we want to use the patched gcc (CC=gcc-7). Since > this was my plan before knowing about the backports I already done some > of the work for this (one search patch issue is not resolved yet). The > downside is that the version jump (gcc-6 (or gcc-5 in R3.2) to gcc-7) > might create problems with vmm-xen and linux-kernel. > > Build an extra package with the gcc version as used by Fedora (as above > C only). This would avoid the gcc version jump, but it might be trickier > to get two variants of gcc with the same version to co-install without > path conflicts. > > What do you think? I'd go with backporting patches to original Fedora's gcc. > My current state (variant 1 (i.e. patch main gcc package)): > > https://github.com/HW42/qubes-vmm-xen/tree/hw42/sp2 I've just merged xen.spec rework, sorry... > https://github.com/HW42/qubes-gcc - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlqTW8EACgkQ24/THMrX 1yzicgf+NhVdSI/rngU0RC24N21JZGqS9mDf+WTC91cmLeht0V07Prook2eDURan KQVyeVFLm9UxfIWksKLCfq0oEqhM0na1SAHzp/OycykhND4jg0ZtDU5JAW4jYyok Tu0YVlXIOe2Bs51Hqj2aECeRs56UoPVG7yz+eJ8yIUUppmBoH+l9P7zeWnJkAalh slscWo0pi2St0rkRnAfBvCJF8h6dXQjD0e1q/DMYx1DUssggSpXpIyyGA6ifqG/k tKYe6hWG3EOLG/s415bG0OaqzUrhQlbwnR1cCetTE+bmiJQE7Pkp+3VW/kloTWji /weTdW8+1we4R7Zw6rE+GCNUdlADWw== =zv9B -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscri
[qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 02/25/2018 01:53 PM, Simon Gaiser wrote: > - The Fedora gcc package build seems to be flacky. It failed twice for >me with different errors (both verry likely unrelated to the backport >patches). Assigning a lot of memory to the build VM got it working >... And I noticed that a bunch of tests are failing but apparently >that's not a reason to break the package build ... I don't know if this will help, but if you're going to recompile gcc-6 anyway, perhaps it's worthwhile updating the snapshot the src rpm is using too (the latest is gcc-6-20180221.tar.xz)? gcc-6 is still maintained by upstream and the instructions on how to do so are in the spec file itself (the revision code you'd want is 257883, or you could download the tar ball directly): https://gcc.gnu.org/ml/gcc/2018-02/msg00162.html It could be that the retpoline patches are already included, in which case, there'd be no manual patching needed and there'd be the benefit of having all the bug and security fixes since FC25 went EOL be included too. If it works, gcc-6 should also build in FC23 with no additional upgrades to libraries, so maybe it'd be worthwhile doing since gcc-5 is no longer maintained by upstream gcc. If wanting to backport gcc-7.3 to FC23 and FC25, the only other library that would absolutely be needed to be upgraded is isl and isl-devel. You could use the FC26 src rpms for both isl/isl-devel and gcc for that. -- 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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/p7031d%24c0%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
