Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 13:04:15 UTC, Wojtek Porczyk wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Tue, Feb 20, 2018 at 01:21:30PM +0100, 'Tom Zander' via qubes-devel wrote:
> > On Tuesday, 20 February 2018 01:49:37 CET Marek Marczykowski-Górecki wrote:
> > > We've decided to deprecate the '$' character from qrexec-related usage.
> > > Instead, to denote special tokens, we will use the '@' character,
> > > which we believe is less likely to be interpreted in a special way
> > > by the relevant software.
> >
> > I would argue against the @ sign on account that it is a special character
> > in bash as well.
> >
> > Search for it here;
> > https://linux.die.net/man/1/bash
> > I don't immediately see a way to exploit it, but why risk it?
>
> We absolutely need a special character that is not allowed in qube name to
> make the special tokens immediately obvious in policy. The process I used was
> to list available characters (POSIX Portable Character Set [1]) and substract
> the characters that are special to some relevant things:
> - - qube name: a-z A-Z 0-9 _ -
> - - POSIX shell [2]: |&;<>()$`\\"'*?[#~=% and the space, tab and newline
> - - POSIX shell reserved words [3]: ! { }
> - - non-POSIX things [3]: [ ]
> - - special qrexec character: +
> - - path separators (POSIX and NT): / \ :
> - - regular expressions: ^. (and other already excluded)
>
> This leaves: '\0\a\b,@'. The point is, all characters are special to
> something. I'm sure if I searched for more "special" characters, I'd find them
> ('\0' is special to C strings, '\a' and '\b' to terminal, '@' in emails, and
> ',' we use in other context in policy). So I stopped there and by consensus we
> picked '@'.
>
> If I missed something, could you please point out? I know shell just good
> enough to know that it's not possible to know every shell quirk. :)
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html
> [2]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02
> [3]
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_04
>
>
> - --
> pozdrawiam / best regards _.-._
> Wojtek Porczyk .-^' '^-.
> Invisible Things Lab |'-.-^-.-'|
> | | | |
> I do not fear computers,| '-.-' |
> I fear lack of them.'-._ : ,-'
> -- Isaac Asimov `^-^-_>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBCAAGBQJajBzCAAoJEL9r2TIQOiNRCvUQALLk151eBxc4URbBvWMQhTFy
> 24T8WygKzNutv+cIW/YlY1FVrPUcwtlJMCbj99mX45ZanHZLDNTEMKC6J1WS4tlg
> SOo0r0U0SnAbUiNvKTsMiydRZDt05gmgxITRxxpCK0FN9WvxEZDF2N67XIwyd0nm
> 0bPyj3cguN5FJlW6dWkUS6/XoLCn6fCX6hGd0wvJFaujGcQkrL6gKYncp8dS3VfO
> 72hZd04vraZFaBEIg2kPhtff5jGpZaB/gI6wfZVeZKzewlHimVz/Efneh8bdeU7f
> MSTqwp+RJOCIHXPxPjs3ARZQYPQIsj6XDL+UFk47sZK8p5fNRlDu9tgsWYHpMPwQ
> TrvEkzAdVXHJpb6prpStfI0gLdcI9TmR8D2hCMEyHYICc9cahET3TPyVmuyKoBuf
> BzLfhaLhv1mC6/aNR+/kgEAfW0ZZM8o6Dedbccz8Tuu/fc8c2A3JqlOKbVcmBc3x
> 9wK8CTrY08dsse8YnywbaxhK5+o01miaL3Uhf9LTbyxsVNAlvavdUWnlrxl/1e3O
> 2f4bTIFXLJ4jLpsmy+e0Itg1/IKnPWZs9uCouDZ8G601pz9p4ORPZJwWa9Cykllb
> /PAlVwx/GJm2qPGxP4lxX2+2T2QXRhoCJTHBp9zoFyzQ7xqTFALEZtC3CRWvT1dr
> t9joU8uqhcS4Wt6nA9lh
> =EN6G
> -END PGP SIGNATURE-
I fail to grasp fully the problem. Could you maybe provide an example of an
attack (sourceVM script and sourceVMname, policy and targetVM script).
After multiple rewording on my understanding and reading some doc I have the
feeling that I am getting closer.
The policy validation service evaluate the policy file and does not interpolate
the string with $. It compares $variable (as a string) with a set of strings
(i.e. $dispvm, $tag, etc...). Are you not able to white-list this part?
Or to use non authorized character in the policy file but keep $ in the
sourceVMscript (is it what you suggested). Or use a trailing character as well.
i.e. anon-whonix %dispvm% allow,target=%dispvm%:anon-whonix-dvm
Another option might be to play with the formatting of the policy files
(multiple line per rule)?
i.e. 0 anon-whonix 1 dispvm allow,target=1 dispvm:0 anon-whonix-dvm
('1 ' is $ '0 ' no $).
Is there not also a problem after the policy evaluation with the string
substitution itself in Dom0? policy should be more explicit when no argument is
allowed.
i.e.:
/etc/qubes-rpc/policy/FileCopy+ (default argument policy)
/etc/qubes-rpc/policy/FileCopy (no argument policy)
/etc/qubes-rpc/policy/FileCopy+blah (argument blah policy)
--
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/e855daee-13e4-4f64-b9c7-975cd53f9ad7%40googlegroups.com.
For more options
Re: [qubes-devel] network attach problem after the last updates on 3.2
On 02/23/2018 11:52 AM, Zrubi wrote: I have a strange problem after updating my system (3.2) from the testing repository. Changing the NetVM of a proxyVM, takes longer time than before, but succeed - at least according to Qubes manager (and qvm tools) But after the change, no traffic visible on the virtual interfaces, so no networking after that move. More details: There is no error messages related this issue. But If I want to detach this bugged ProxyVM from the connected AppVM (means: If try to change the connected AppVM's netVM) it is failing with the following error message: Internal error: libxenlight failed to detach network device - -- Zrubi Hello Zrubi, Are you using Linux kernel version "4.14.18-1.pvops.qubes.x86_64"? Are you experiencing higher than normal CPU utilization within the affected VMs due to the "xenbus" and "xenwatch" kernel threads? If the answers are "yes", I believe you have encountered the same issue I reported earlier. Here is a link to my report: https://groups.google.com/d/msg/qubes-devel/ER9v3jy0EeI/4VxLzr4eBQAJ I believe this is a regression in the kernel. Could you try to revert the commit mentioned in my report and see if that resolves the issue? Hope this helps! Vefa -- 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/54b3b2fb-ced8-c986-7d91-021c1c3e7aaa%40runbox.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Friday, February 23, 2018 at 10:58:48 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Feb 23, 2018 at 01:27:41PM -0800, Yuraeitha wrote: > > On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > > > On 22 Feb 2018 4:24 pm, "Yuraeitha" wrote: > > > > > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > > > without confirmation whether it'd any good to do so. I'll probably never > > > find out the reason, but it's starting to make me a bit uneasy whether it > > > could have been due to Qubes RC-3 or not. > > > > > > > > > I wouldn't bet on it. My system is based on rc4. My colleague who > > > installed rc3 did not have the problem. > > > > > > > > > Regards, > > > Elias > > > > > > While my qvm-copy issue is gone, what triggered the issue for me isn't, and > > by the looks of it, it looks like it could happen for another future update > > again, if it hasn't already happened in the past without showing signs of > > it. I believe this may be the reason the qvm-copy issue happend to me, > > although I can't be sure yet. There is also a chance it was the same that > > happened to you? But either way, this is what frequently happens on my > > setup, I started noticing it the last 14 days or so. > > > > Below is a recent example of the template's terminal output when it > > happens. I did the update after work followed up with sleeping, so I'm sure > > it was well beyond the default 6 hours for saving cache on repository > > updates. > > According to dnf.conf manual, "The default corresponds to 48 hours". > > Does it explains anything? > > > This also happened on the second template (fedora-26-apps), and not on the > > first template I ran the update (fedora-26). Could this be because the > > updates are handled in the same place and the cache wasn't cleared? It > > seems likely to be a legit explanation, although remains to be confirmed. > > > > There is also the issue I have with PGP checks, where I have to restart > > sys-net/sys-firewall to get proper PGP checks on updates. > > > > All these seem to be connected to each others. Cache doesn't seem to be > > cleared properly where Qubes handles the updates. I'm not sure if that is > > actually the explanation for the behavior though. It looks like this. > > > > This is from the latest update, the cache issue happens quite frequently > > despite the 6 hour window. > > > > > > [user@fedora-26-apps ~]$ sudo dnf update > > --enablerepo=qubes-vm-*-current-testing > > I'd recommend --refresh option, instead of separate "dnf clean all" > call. This will cause dnf to check if metadata on the server have > updated, and do not download (50+ MB) again if not. > > (...) > > > As it can be seen, in the first update it only checks the fedora > > repository, and no other repositories. > > I haven't observed the details yet, for example I'm not sure if it > > sometimes includes Qubes repository, but not the Qubes current-testing > > repository. I'm not sure if it's a all or nothing situation, or if it can > > be "mixed", for example if current-testing isn't included despite the > > --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know > > it's at least an all or nothing issue, whether it can be mixed is too early > > to tell. > > > > At this point I might just re-install, unless it can be fixed. But it seems > > something is fundamentally broken, it seems safer to get a clean > > re-install. But I wonder if this could have explained the qvm-copy issue. > > Have you installed those updates now? The not-checking-updates issue > seems separate and in fact working as documented (but maybe not as > expected). Other issues, should be fixed in the update. > > - -- > 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/THMrX1ywFAlqQjoEACgkQ24/THMrX > 1yxKAQf8DZYI17fmswIFANu8osyFKhcV3JYVRVUcDbI68HN1r/bQHAdkx+Y68pep > 1oycNtiFYOGrPpzcWlbAVAMNdb/GJYhH/GxQSCRTuufxOFPljvNQtf7pMleeNh21 > dbfNsE8xZpbPTZ35j+baxjsb5jzLCcypUxzjU/1I3WfY9gmjQbXSoIvHacffGBex > nz+6rkFGMLDTULLvQWRkbwLM53oInkWxtU0BpAh6ZW2OyV4SMzFu+NkWnxve3Kw6 > Qx6wEPADErR+k3mVEVwEq0FNsS8CMFiO8JUypbep5N38dBs71ZjVAl1TW6SvuvIH > 4lw96WYVUo1QKcgAAhS4AQiaAdqcjA== > =R+3Z > -END PGP SIGNATURE- If cache last 48 hours and not 6 hours, that certainly could explain it. I'll write down when I do future updates to see if it is gone when beyond 48 hours or if using --refresh within 48 hours. Duly noted on the --refresh option. I've been worried if checking updates more frequently would stress the servers (considering when many people do it), so --refresh seems like a much, much better option. I'll definitely use this from now on. I have indeed in
[qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 02/23/2018 04:08 PM, Marek Marczykowski-Górecki wrote: > 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. Just chiming in, but I believe that the Fedora 26 and 27 Updates repositories has gcc 7.3 now, which has Retpoline support. But if backporting to FC23/25, I *think* glibc would also need to be upgraded, if 7.3 won't compile against the stock glibc found in FC23 and 25. Backporting gcc 7.3 to FC23 may also need a few more additional packages to be upgraded in the toolchain, although I haven't tried it myself. I don't know if this helps, but I *have* tried installing FC27 Updates rpms in an FC25 AppVM and it works fine, at least for compiling kernels. There may be some extra packages here that don't absolutely need to be there, but this is what I installed in an FC25 template cleanly, and if there were additional dependencies needed by these rpms, the FC25 versions of those packages worked fine: cpp-7.3.1-2.fc27.x86_64.rpm gcc-7.3.1-2.fc27.x86_64.rpm gcc-c++-7.3.1-2.fc27.x86_64.rpm gcc-gdb-plugin-7.3.1-2.fc27.x86_64.rpm gcc-gfortran-7.3.1-2.fc27.x86_64.rpm gcc-gnat-7.3.1-2.fc27.x86_64.rpm gcc-go-7.3.1-2.fc27.x86_64.rpm gcc-objc-7.3.1-2.fc27.x86_64.rpm gcc-objc++-7.3.1-2.fc27.x86_64.rpm gcc-plugin-devel-7.3.1-2.fc27.x86_64.rpm glibc-2.26-24.fc27.x86_64.rpm glibc-all-langpacks-2.26-24.fc27.x86_64.rpm glibc-common-2.26-24.fc27.x86_64.rpm glibc-headers-2.26-24.fc27.x86_64.rpm isl-0.16.1-3.fc27.x86_64.rpm libasan-7.3.1-2.fc27.x86_64.rpm libasan-static-7.3.1-2.fc27.x86_64.rpm libatomic-7.3.1-2.fc27.x86_64.rpm libatomic-static-7.3.1-2.fc27.x86_64.rpm libcilkrts-7.3.1-2.fc27.x86_64.rpm libcilkrts-static-7.3.1-2.fc27.x86_64.rpm libgcc-7.3.1-2.fc27.x86_64.rpm libgccjit-7.3.1-2.fc27.x86_64.rpm libgccjit-devel-7.3.1-2.fc27.x86_64.rpm libgfortran-7.3.1-2.fc27.x86_64.rpm libgfortran-static-7.3.1-2.fc27.x86_64.rpm libgnat-7.3.1-2.fc27.x86_64.rpm libgnat-devel-7.3.1-2.fc27.x86_64.rpm libgnat-static-7.3.1-2.fc27.x86_64.rpm libgo-7.3.1-2.fc27.x86_64.rpm libgo-devel-7.3.1-2.fc27.x86_64.rpm libgomp-7.3.1-2.fc27.x86_64.rpm libgomp-offload-nvptx-7.3.1-2.fc27.x86_64.rpm libgo-static-7.3.1-2.fc27.x86_64.rpm libitm-7.3.1-2.fc27.x86_64.rpm libitm-devel-7.3.1-2.fc27.x86_64.rpm libitm-static-7.3.1-2.fc27.x86_64.rpm liblsan-7.3.1-2.fc27.x86_64.rpm liblsan-static-7.3.1-2.fc27.x86_64.rpm libobjc-7.3.1-2.fc27.x86_64.rpm libquadmath-7.3.1-2.fc27.x86_64.rpm libquadmath-devel-7.3.1-2.fc27.x86_64.rpm libquadmath-static-7.3.1-2.fc27.x86_64.rpm libstdc++-7.3.1-2.fc27.x86_64.rpm libstdc++-devel-7.3.1-2.fc27.x86_64.rpm libstdc++-docs-7.3.1-2.fc27.x86_64.rpm libstdc++-static-7.3.1-2.fc27.x86_64.rpm libtsan-7.3.1-2.fc27.x86_64.rpm libtsan-static-7.3.1-2.fc27.x86_64.rpm libubsan-7.3.1-2.fc27.x86_64.rpm libubsan-static-7.3.1-2.fc27.x86_64.rpm -- 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/p6q7l8%24obo%241%40blaine.gmane.org. 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 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. > And a side question about qubes-builder: Does it build in a chroot? Yes. > I'd > like to attempt to backport a build environment that has a > retpoline-enabled version of gcc, and I'm wondering if I could just > bypass qubes-builder entirely and run make rpms-dom0 in a build > environment where I've manually upgraded the gcc version to be > Retpoline-compatible in an FC23 or FC25 template like I do when I > compile my own kernels. In theory - yes. In practice, no one have tried that for a long time. > Also: Are there any dangers in compiling the Xen rpms in an FC25 > template and then installing them in R3.2 dom0's FC23 environment? For xen-hypervisor package it should be ok. And this is the only one you should care about here. For other packages, especially xen-libs and xen-runtime, resulting binaries most likely will not work in older environment (linked libraries versions etc). - -- 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/THMrX1ywFAlqQnwgACgkQ24/THMrX 1yw9DAgAmhydEgfCb/A0xzVAHVXzjMi18kWMmgU54IVOjjuBfE3oIFyXKna1jSb2 Y7OdrA91yc2F87bsiBrXlDaqJlM1HHs3vvjsnq4KZ1+LI8DhEWaEkki2govzmkSi w21+QZ4IC5BIwUFO7HF3beTlxnI3p+/3vfVg+956bsmvQDYSjLVi3t5TiMBrtsmI Hfizzl2sjH5Y5LYlbM5vUTYGQ0BdIk2ZF7EQeSZ4PjoBAzKy5DAUlWa429eZzT9R 7GzAR1E/t+eAJhZT1tCo0CPvehboMsTVj0xgRZi9BfEVDdYwcbI6t09nAy0SauWc 0RR1n1pHJFgwaExyMo5HNEQteuDMoQ== =O1Qg -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/20180223230831.GL2023%40mail-itl. 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)
On Fri, February 23, 2018 10:27 pm, Reg Tiangha wrote:
> And a side question about qubes-builder: Does it build in a chroot? I'd
> like to attempt to backport a build environment that has a
> retpoline-enabled version of gcc, and I'm wondering if I could just bypass
> qubes-builder entirely and run make rpms-dom0 in a build environment where
> I've manually upgraded the gcc version to be
> Retpoline-compatible in an FC23 or FC25 template like I do when I
> compile my own kernels.
>
> Also: Are there any dangers in compiling the Xen rpms in an FC25
> template and then installing them in R3.2 dom0's FC23 environment? Or
> should I just build it in an FC23 environment to be safe? I haven't
> encountered any issues in doing that with kernels (although I don't
> compile third-party out-of-tree kernel drivers either), but I don't know
> what Xen would link against during compilation to know if that's safe to
> do or not.
qubes-builder builds Xen etc. inside a Fedora 25 chroot. So you can do:
sudo chroot chroot-fc25
cd /home/user
su -c 'make -C rpmbuild/BUILD/xen-4.8.2/xen menuconfig' - user
su -c 'make -C rpmbuild/BUILD/xen-4.8.2/xen' - user
Then get compiled Xen binary from
chroot-fc25/home/user/rpmbuild/BUILD/xen-4.8.2/xen/xen.{gz,efi}
(Credit to Marek). That's for 4.0, 3.2 is an fc23 chroot. Not sure if that
answers all your questions.
--
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/796ced26459496ce84813fe3933c609c.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
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 And a side question about qubes-builder: Does it build in a chroot? I'd like to attempt to backport a build environment that has a retpoline-enabled version of gcc, and I'm wondering if I could just bypass qubes-builder entirely and run make rpms-dom0 in a build environment where I've manually upgraded the gcc version to be Retpoline-compatible in an FC23 or FC25 template like I do when I compile my own kernels. Also: Are there any dangers in compiling the Xen rpms in an FC25 template and then installing them in R3.2 dom0's FC23 environment? Or should I just build it in an FC23 environment to be safe? I haven't encountered any issues in doing that with kernels (although I don't compile third-party out-of-tree kernel drivers either), but I don't know what Xen would link against during compilation to know if that's safe to do or not. -- 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/p6q4cv%24etf%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Feb 23, 2018 at 01:27:41PM -0800, Yuraeitha wrote: > On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > > On 22 Feb 2018 4:24 pm, "Yuraeitha" wrote: > > > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > > without confirmation whether it'd any good to do so. I'll probably never > > find out the reason, but it's starting to make me a bit uneasy whether it > > could have been due to Qubes RC-3 or not. > > > > > > I wouldn't bet on it. My system is based on rc4. My colleague who installed > > rc3 did not have the problem. > > > > > > Regards, > > Elias > > > While my qvm-copy issue is gone, what triggered the issue for me isn't, and > by the looks of it, it looks like it could happen for another future update > again, if it hasn't already happened in the past without showing signs of it. > I believe this may be the reason the qvm-copy issue happend to me, although I > can't be sure yet. There is also a chance it was the same that happened to > you? But either way, this is what frequently happens on my setup, I started > noticing it the last 14 days or so. > > Below is a recent example of the template's terminal output when it happens. > I did the update after work followed up with sleeping, so I'm sure it was > well beyond the default 6 hours for saving cache on repository updates. According to dnf.conf manual, "The default corresponds to 48 hours". Does it explains anything? > This also happened on the second template (fedora-26-apps), and not on the > first template I ran the update (fedora-26). Could this be because the > updates are handled in the same place and the cache wasn't cleared? It seems > likely to be a legit explanation, although remains to be confirmed. > > There is also the issue I have with PGP checks, where I have to restart > sys-net/sys-firewall to get proper PGP checks on updates. > > All these seem to be connected to each others. Cache doesn't seem to be > cleared properly where Qubes handles the updates. I'm not sure if that is > actually the explanation for the behavior though. It looks like this. > > This is from the latest update, the cache issue happens quite frequently > despite the 6 hour window. > > > [user@fedora-26-apps ~]$ sudo dnf update > --enablerepo=qubes-vm-*-current-testing I'd recommend --refresh option, instead of separate "dnf clean all" call. This will cause dnf to check if metadata on the server have updated, and do not download (50+ MB) again if not. (...) > As it can be seen, in the first update it only checks the fedora repository, > and no other repositories. > I haven't observed the details yet, for example I'm not sure if it sometimes > includes Qubes repository, but not the Qubes current-testing repository. I'm > not sure if it's a all or nothing situation, or if it can be "mixed", for > example if current-testing isn't included despite the > --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know > it's at least an all or nothing issue, whether it can be mixed is too early > to tell. > > At this point I might just re-install, unless it can be fixed. But it seems > something is fundamentally broken, it seems safer to get a clean re-install. > But I wonder if this could have explained the qvm-copy issue. Have you installed those updates now? The not-checking-updates issue seems separate and in fact working as documented (but maybe not as expected). Other issues, should be fixed in the update. - -- 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/THMrX1ywFAlqQjoEACgkQ24/THMrX 1yxKAQf8DZYI17fmswIFANu8osyFKhcV3JYVRVUcDbI68HN1r/bQHAdkx+Y68pep 1oycNtiFYOGrPpzcWlbAVAMNdb/GJYhH/GxQSCRTuufxOFPljvNQtf7pMleeNh21 dbfNsE8xZpbPTZ35j+baxjsb5jzLCcypUxzjU/1I3WfY9gmjQbXSoIvHacffGBex nz+6rkFGMLDTULLvQWRkbwLM53oInkWxtU0BpAh6ZW2OyV4SMzFu+NkWnxve3Kw6 Qx6wEPADErR+k3mVEVwEq0FNsS8CMFiO8JUypbep5N38dBs71ZjVAl1TW6SvuvIH 4lw96WYVUo1QKcgAAhS4AQiaAdqcjA== =R+3Z -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/20180223215800.GK2023%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > On 22 Feb 2018 4:24 pm, "Yuraeitha" wrote: > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > without confirmation whether it'd any good to do so. I'll probably never find > out the reason, but it's starting to make me a bit uneasy whether it could > have been due to Qubes RC-3 or not. > > > I wouldn't bet on it. My system is based on rc4. My colleague who installed > rc3 did not have the problem. > > > Regards, > Elias GPG*, I mixed that acronym up with PGP in the above post. It should also be noted that fedora-26-apps is the only AppVM I have RPM Fusion for Fedora 26 - Free RPM Fusion for Fedora 26 - Nonfree enabled, which further deepens the mystery. If the cache isn't cleared from the earlier fedora-26 update just before updating fedora-26-apps, then why wasn't RPM Fusion repositories checked on the first update run in fedora-26-apps? It still seems to be a cache issue in the shared Qubes template update mechanism (and it also sometimes affects dom0 update as well). But it may be important to include that that RPM Fusion did not update, despite no other RPM update had been run within the 6 hour window, although fedora/qubes updates had been run minutes before the issue. Also this only happens to fedora, I've never encountered the issue on the debian template. I also only have one debian template, not 3 (dom0, fedora-26, and fedora-26-apps). Putting it short, it seems whenever recent version of Qubes 4 update with multiple of the same architectures (fedora-26), it has cache issues. At the very least this happens on my Qubes system, I've not yet seen others report this. Could it be a unique issue? -- 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/37c6e917-99cd-4b1a-a9f8-1239e8109b68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Thursday, February 22, 2018 at 9:26:42 AM UTC+1, Elias Mårtenson wrote: > On 22 Feb 2018 4:24 pm, "Yuraeitha" wrote: > > Guess I'll draw the long straw, and just get rid of RC-3 and install RC-4 > without confirmation whether it'd any good to do so. I'll probably never find > out the reason, but it's starting to make me a bit uneasy whether it could > have been due to Qubes RC-3 or not. > > > I wouldn't bet on it. My system is based on rc4. My colleague who installed > rc3 did not have the problem. > > > Regards, > Elias While my qvm-copy issue is gone, what triggered the issue for me isn't, and by the looks of it, it looks like it could happen for another future update again, if it hasn't already happened in the past without showing signs of it. I believe this may be the reason the qvm-copy issue happend to me, although I can't be sure yet. There is also a chance it was the same that happened to you? But either way, this is what frequently happens on my setup, I started noticing it the last 14 days or so. Below is a recent example of the template's terminal output when it happens. I did the update after work followed up with sleeping, so I'm sure it was well beyond the default 6 hours for saving cache on repository updates. This also happened on the second template (fedora-26-apps), and not on the first template I ran the update (fedora-26). Could this be because the updates are handled in the same place and the cache wasn't cleared? It seems likely to be a legit explanation, although remains to be confirmed. There is also the issue I have with PGP checks, where I have to restart sys-net/sys-firewall to get proper PGP checks on updates. All these seem to be connected to each others. Cache doesn't seem to be cleared properly where Qubes handles the updates. I'm not sure if that is actually the explanation for the behavior though. It looks like this. This is from the latest update, the cache issue happens quite frequently despite the 6 hour window. [user@fedora-26-apps ~]$ sudo dnf update --enablerepo=qubes-vm-*-current-testing Fedora 26 - x86_64 - Updates2.3 MB/s | 20 MB 00:08 Last metadata expiration check: 0:00:12 ago on Feb Dependencies resolved. Nothing to do. Complete! [user@fedora-26-apps ~]$ sudo dnf clean all 44 files removed [user@fedora-26-apps ~]$ sudo dnf update --enablerepo=qubes-vm-*-current-testing Fedora 26 - x86_64 - Updates2.2 MB/s | 20 MB 00:09 Fedora 26 - x86_64 2.5 MB/s | 53 MB 00:21 Qubes OS Repository for VM (updates)106 kB/s | 55 kB 00:00 Qubes OS Repository for VM (updates-testing)291 kB/s | 182 kB 00:00 RPM Fusion for Fedora 26 - Free 1.0 MB/s | 519 kB 00:00 RPM Fusion for Fedora 26 - Nonfree 322 kB/s | 158 kB 00:00 Last metadata expiration check: 0:00:00 ago on Feb Dependencies resolved. Package Arch Version Repository Size Upgrading: python3-dnf-plugins-qubes-hooks x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.9 k qubes-core-agent x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 107 k qubes-core-agent-dom0-updates x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.3 k qubes-core-agent-nautilus x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 11 k qubes-core-agent-network-manager x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 9.3 k qubes-core-agent-networking x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 17 k qubes-core-agent-passwordless-root x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 8.5 k qubes-core-agent-qrexec x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 30 k qubes-core-agent-systemd x86_64 4.0.23-1.fc26 qubes-vm-r4.0-current-testing 22 k Transaction Summary Upgrade 9 Packages Total download size: 222 k Is this ok [y/N]: As it can be seen, in the first update it only checks the fedora repository, and no other repositories. I haven't observed the details yet, for example I'm not sure if it sometimes includes Qubes repository, but not the Qubes current-testing repository. I'm not sure if it's a all or nothing situation, or if it can be "mixed", for example if current-testing isn't included despite the --enablerepo=qubes-vm-*-current-testing flag. For now though, I just know it's at least an all or nothing issue, whether it can be mixed is too early to tell. At this point I might just re-install, unless it can be fixed. But it seems somethi
Re: [qubes-devel] network attach problem after the last updates on 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/23/2018 11:52 AM, Zrubi wrote: > I have a strange problem after updating my system (3.2) from the > testing repository. > > Changing the NetVM of a proxyVM, takes longer time than before, > but succeed - at least according to Qubes manager (and qvm tools) > But after the change, no traffic visible on the virtual interfaces, > so no networking after that move. More details: There is no error messages related this issue. But If I want to detach this bugged ProxyVM from the connected AppVM (means: If try to change the connected AppVM's netVM) it is failing with the following error message: Internal error: libxenlight failed to detach network device - -- Zrubi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlqP9gwACgkQGjNaC1SP N2QV1BAAiO5ddDajHGV3Q/Avt+13X3tDnfrkzCfqZd63LF3VVpHqTG82xHQmDESU x5HHZf4Uaq/Tj9oWMVpFbcrU6RpjDOXvteVnzRwI/i+bAQlk+O4rWNi4vR0+zH6G rb1RrxDZ3dy18m1exeH72hodOIK2ec/FIEHD33ROYPW4Ey9aVGOpsTyLlT/U1LyA IB1BSF6/T804eR5xAquADrtPc4PLLdLQbRF6hV5T28dobOcaB+y2rkBURDJywNvB zS/4GQNY+eZAr/1JAjDD7YidqF+xWWMTJGJoi5+1vrx7RA0EcPJ0GKreLnFXJSGO 7AK1sQfJ1x2iwQly8FjustqCIhALiMAIkzcmhGkCT5dcKWccbYeJbWSnIHLHN6Bn 7nKgsSh5Mz/OwqPBi07Q8Qa+RF9IUSrnQW65solauTMe4u0prAOiKYL/Ey/eOBi0 9klAgIhDPBXicKzONsLiup6Nms7Vl+5CDgylR2wmjuXeURrReh0IihTINP5khenV +Bgk2wuoTFuwbqFR2sEGL0rBCCRYmBTgvOmH15sRYIIl8GdpeSagcA3wLBxH3Urn Dt5SzJvzL9DVdsHXVD7VMWQSCzrzYbejDcyTwtgMJaJqsfGxO4oueMS+gFeuK5w2 2b/QVUZag3TCnKX5SB9plFfWMXIk1eCiFcJCqADdpcSTA+G1Q1s= =OG9u -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/eb8c53cd-3520-b352-3a7c-482e7bf59b73%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] network attach problem after the last updates on 3.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I have a strange problem after updating my system (3.2) from the testing repository. Changing the NetVM of a proxyVM, takes longer time than before, but succeed - at least according to Qubes manager (and qvm tools) But after the change, no traffic visible on the virtual interfaces, so no networking after that move. I need to reboot the proxyVM (and all the connected AppVMs) to restore networking. It seems only affecting ProxyVMs - at least my newly started dipVM's without netVM are not affected, I can change it's netVM without any issu e. Any idea what went wrong? Thanks. - -- Zrubi -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlqP8mgACgkQGjNaC1SP N2RmtRAApM/dhapfHuJXv7zK1b7NDykOX8iJqxVE3wW3Zw/Rz9K6MlIQ415MAYyb 7ywrjXf5O8BB50lJR86BbM9cNd6Bipdu/X896HT7tbKQOSfbz/CzbwBOqZH02RwV uq2JUUFVN93+WAgRkW4XgNiKFaPzIDeF9CxfPykwEIWcGHq1nqWqQWdXAIQ/6Cjs jNxOlIUcuX2ItFfd2H8ym5s3af6IQ7LUUUFZAtNXrvn44nFZO4bUnCPNj/87lptX ruwZNNv9GpEie2gEkw/JAoaM/yLriw0M4cK+Ljt+bS5VjSk/4xzo54+waKaGVKDl 7Od44wPkjonj28a8LEnMiIQf/goflA8QslejCQhtYoKIQehNTE94iUGlnt++iyl0 J6zSbYLQLwzhBG7kwwaebKFQgX3f2nGIJgcdHZHxoZjICKzjBXZmoDB9fI57NUue 3x2654eX4UTJHfk0uUvpc0HRz8RvyvrW4Xuy1yL7xne7S6agit9V42gu5XtYHg6u MnYpk9NxFPzRFu/CxyWYlD5EbyHUa3Z48AMqPsCr9wscxWNtvKh7NfS/1WkTX49u N11pGFqkl4V5lbuM09f3uns3FQJMg2oqyuEyg8yoQj+wis2/kBhU6yvEYnAtJzNi lTzU93x83SDqyPjs5XY0lmINlKnlFc3H+eJnWaXuoIQRlUVj0aI= =indN -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/05031ade-b019-986e-e378-32cc8fff916e%40zrubi.hu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] QSB #38: Qrexec policy bypass and possible information leak
On Wed, February 21, 2018 11:35 am, 'Tom Zander' via qubes-devel wrote: > The point of a variable that is passed from a VM to the dom0 qrexec > daemon is that your source VM doesn't have to know about who is $adminVM > or what is the actually started dispVM's name. QRexec daemon (in dom0) > should do the variable replacement before the user request leaves > qrexec-daemon running in dom0. Just like bash does the replacement before > it forwards the command-line. Not to beat a dead horse, but is there anything to this concept? Should the variable expansion take place somewhere earlier in the pipeline instead of at the target, or is that not something to worry about? -- 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/eff4a6e79834a62d061b4fad52b278a7.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
