Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Wednesday, 21 February 2018 02:26:16 UTC+8, Marek Marczykowski-Górecki wrote: > qvm-copy command takes only filename, the VM name you give in qrexec > confirmation prompt. After doing a full reboot of the system, and making sure that everything is updated, qvm-copy-to-vm now works, but qvm-copy still gives me the permission error. As the Nautilus integration uses qvm-copy (rather than qvm-copy-to-vm) it too fails, in the same way as before. A colleague of mine who installed rc3 (and has updated everything from testing since) just did a full update and he's not seeing the same problem. Regards, Elias -- 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/68b18bf2-41cd-4624-95da-14c132f7804b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Permission denied when using Qubes().domains
Using python3 in dom0, trying to access qubes.Qubes().domains results in the following error: /dev/mapper/control: open failed: Permission denied Failure to communicate with kernel device-mapper driver. Incompatible libdevmapper 1.02.136 [...] and kernel driver It does work when using 'sudo python3' instead. I don't know if this is considered normal behavior or a bug, as I would normally expect admin objects to be accessible with normal user privs. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/6f0e7641-da0e-5e3b-817a-a69932c6ad76%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 7:26:16 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 09:07:34AM -0800, Yuraeitha wrote: > > - The GUI copy to VM now works, but the terminal qvm-copy still doesn't > > work. > > qvm-copy command takes only filename, the VM name you give in qrexec > confirmation prompt. > > - -- > 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/THMrX1ywFAlqMaBcACgkQ24/THMrX > 1yxRQgf/YtF1OCeg/iwryngYe+4PI0tv6x9h+ZZISzL1ppVCTEyWa2PJouDZ9GeB > OVZSlGnu/0hmEd4CsXzGsu011PHRYK5dPeQFMq3EmywJQy9gXQh72ifkqZbYscO3 > WuXYHf8NK/OzxlUZHCKrpurjFtOLZpZTXa79UMd1lkscmnpS0PAI72Nqi0xd6mJf > DQ81u0tzh57QQmM3qJJSFBMMac6TR9i0zSvEWVacYVuzdIeFSMEf1v4GqPRG2lsQ > 3xNQvm76JQ/WU0s886qNCl0Q3M7kZ41OlH7gy1PhG9QINBUW1aacnxLXrKP3zNu6 > psvUm9UaEu2cFpLLRF5FV2FBE0xHNA== > =/if3 > -END PGP SIGNATURE- ah I see, that really simplifies the command compared to the old, or maybe it was always like that in VM's and I didn't realize. Either way though, the issue is still there without putting the VM name in the command, but now the "Request refused." is back in the place of the error. It strikes me as a little odd that it changed on its own this time without me doing anything new (I did nothing special except restarting the VM in question, perhaps it was that). It's the same changed feedback (from error to missing permission) if applying the VM name in the command. This is a peculiar oddball error. Multiple of full system restarts, and it just won't go away despite careful maintenance procedures, or so I would like to think anyway. (i.e. I don't just recklessly update with wrong repositories between dom0/templates, plug the power, etc.). This is not a personal issue for me though, not yet at least. I'll wait and see if something new happens, right now I don't think I can add anything new. Now that full 10-12 second long system-wide freeze that happened earlier today after the update, worries me a bit more. But it hasn't happened since then though. It wasn't too long after returning from suspend, and occurred immediately after starting a another VM. I had little spare RAM left at the time (8GB total) and more VM's running than normal, so maybe that's part of the issue, but normally it would just not start if not enough RAM is left and not cause a freeze like that. I don't expect a personal followup on this, I'm only mentioning this one time incident for awareness. At the time of the system-wide freeze, it had only been restarted once after the update. If a second restart could fix something like that, then maybe it's gone now *shrug* -- 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/ca684ebb-c9e6-4d6f-80b8-2a0c2a9904c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 19:41:19 CET Marek Marczykowski-Górecki wrote: > > On the 'other' side of qrexec (on dom0) you have perfect control over > > the > > situation and you also don't have any need for recoding or encodings or > > anything like that. It still is just 8 bits data, not encoded. > > And then, after policy evaluation, you pass that data to actual service > to execute the operation (which may be in dom0 or another VM). Yes, WITHOUT the escape character. Remember, you escape the special names of VM names that dom0 will substitute. “$adminvm” doesn't end up being the string you offer to qubesd, the string “dom0” is. Likewise; you don't start a service in Dispvm18431 and send it the text “$dispvm”. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/2032074.AZcuCm27fB%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 06:57:34PM +0100, Tom Zander wrote: > On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > > The thing you have to rememeber is that the escape character never needs > > > to be typed by the user. > > > In QRexec you are defining an API, applications like qvm-run are using > > > that API. What the user passes into qvm-run and what is actually sent > > > to dom0 does not have to be identical. > > > > In theory yes, but this would introduce more complexity to this code > > (taking care where which encoding is used etc). > > I read the code, there is no encoding. > You correctly used the POSIX Portable Character Set for text. So no need > for encoding. > When you use the qrexec API you just sent a struct with some arrays of bytes > for VM names. > In your qrexec code you use an array of unsigned chars. Also, no encoding. > > The point is that you use encodings only when you have **text** with > characters > 127. Which you don't allow. > > The problem you fear doesn't exist. > > The reason is because when accepting user-input you use encodings. > > When your app starts talking to qrexec/qubsed there is no longer any > encoding. Just an 8-bit bytearray. The text has been standardized. > > On the 'other' side of qrexec (on dom0) you have perfect control over the > situation and you also don't have any need for recoding or encodings or > anything like that. It still is just 8 bits data, not encoded. And then, after policy evaluation, you pass that data to actual service to execute the operation (which may be in dom0 or another VM). > > > I guess you do the translation currently as well; '$' turns into '@' in > > > your new code. > > > > > > The consequence of this is that you don't have to limit yourself to the > > > posix list. > > > Using the portable characters set for a non-character simply isn't > > > needed. > > > > > > So, knowing that your API is actually based on 8-bit characters and not > > > 7 > > > bits which you are limiting yourself to, my suggestion is to take > > > something above 127 and below 256 as a special char. > > > Most fun one would be “ÿ” which is a normal character you can pass on a > > > shell script if you must, its actual byte-value is 0xFF > > > > Until some helpful application (shell or else) will try to interpret it > > as UTF-8. > > Ehm, how would “some helpful application” manage to get in your qrexec > policy-frameowork? If you fear that you have bigger issues as they could > replace anything with anything... I'm not sure if you've read the QSB carefully. The problem is how the thing executing the service handle arguments. Not policy evaluating part - - there '$' or other potentially shell special characters are handled correctly. Anyone can write a qrexec service, and we want to provide a framework that make it hard to shoot yourself in the foot. > Anyway, to answer your fear. > > No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. > (see attached example file) Or, more likely, it will just switch off utf-8. > - -- 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/THMrX1ywFAlqMa8cACgkQ24/THMrX 1yyE6gf+McyBJoK/NW4KAfYEL5xritven8tl35yXaWND674jddKz/WXMaaf9mdar 338xMDBLoeDMZvYVpujd2+lbbnwyMPOUvxGtDQ87R+mluWX5YkWcrzNgVWhrjbJu GTczmlkCT+PaW5cYonXCvFMzGyB3Afu2T7BMBD947RU2SUpiaooAfUUqpS1dCGG8 cQF8xe2Ab3vCBF1e1ocOEF5KRYgsC8NsTc1KDqlDp9AORqfLOINHv0ZNFS/Gaksn CLqvKO5VPr+oswHm8v5I4MLQPK5cQuFvn7oJOs3+pOzZqVk9y7xvjZ4xKiVNF4pB tK0B3Tpp3F0VzI9fhAoYHi4pI2PSUg== =mIGj -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/20180220184119.GG2084%40mail-itl. 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 Tue, Feb 20, 2018 at 09:07:34AM -0800, Yuraeitha wrote: > - The GUI copy to VM now works, but the terminal qvm-copy still doesn't work. qvm-copy command takes only filename, the VM name you give in qrexec confirmation prompt. - -- 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/THMrX1ywFAlqMaBcACgkQ24/THMrX 1yxRQgf/YtF1OCeg/iwryngYe+4PI0tv6x9h+ZZISzL1ppVCTEyWa2PJouDZ9GeB OVZSlGnu/0hmEd4CsXzGsu011PHRYK5dPeQFMq3EmywJQy9gXQh72ifkqZbYscO3 WuXYHf8NK/OzxlUZHCKrpurjFtOLZpZTXa79UMd1lkscmnpS0PAI72Nqi0xd6mJf DQ81u0tzh57QQmM3qJJSFBMMac6TR9i0zSvEWVacYVuzdIeFSMEf1v4GqPRG2lsQ 3xNQvm76JQ/WU0s886qNCl0Q3M7kZ41OlH7gy1PhG9QINBUW1aacnxLXrKP3zNu6 psvUm9UaEu2cFpLLRF5FV2FBE0xHNA== =/if3 -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/20180220182535.GF2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
I also had qvm-copy and other rpc requests fail after yesterday's updates with "Request refused". I restarted and everything seems okay now. Original Message On February 20, 2018 10:24 AM, Elias Mårtenson wrote: > >After doing the most recent qubes-dom0-update from the testing repository, all >RPC calls from one VM to another stopped working. Calls from dom0 still works >fine. > > By "not working" I mean that the call to qrexec-client-vm gives me a "Request > refused". > > This includes calls to qvm-copy as well, since it uses the qubes.Filecopy RPC > call. > > Is this a known problem? > > Regards, > Elias > > >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/9606becc-5c00-46c6-bb06-28ae90624a18%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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/CgjzZC77gVrGUVfH6H2ocTepOaGYMUXXon0M-mqauBRd6tu4Vp9QlRipqkfEhmDOGhniU5sQYLfz7hxAojEXDBVq-gQImmGsAfNDEkESRDo%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 16:54:36 CET Marek Marczykowski-Górecki wrote: > > The thing you have to rememeber is that the escape character never needs > > to be typed by the user. > > In QRexec you are defining an API, applications like qvm-run are using > > that API. What the user passes into qvm-run and what is actually sent > > to dom0 does not have to be identical. > > In theory yes, but this would introduce more complexity to this code > (taking care where which encoding is used etc). I read the code, there is no encoding. You correctly used the POSIX Portable Character Set for text. So no need for encoding. When you use the qrexec API you just sent a struct with some arrays of bytes for VM names. In your qrexec code you use an array of unsigned chars. Also, no encoding. The point is that you use encodings only when you have **text** with characters > 127. Which you don't allow. The problem you fear doesn't exist. The reason is because when accepting user-input you use encodings. When your app starts talking to qrexec/qubsed there is no longer any encoding. Just an 8-bit bytearray. The text has been standardized. On the 'other' side of qrexec (on dom0) you have perfect control over the situation and you also don't have any need for recoding or encodings or anything like that. It still is just 8 bits data, not encoded. > > I guess you do the translation currently as well; '$' turns into '@' in > > your new code. > > > > The consequence of this is that you don't have to limit yourself to the > > posix list. > > Using the portable characters set for a non-character simply isn't > > needed. > > > > So, knowing that your API is actually based on 8-bit characters and not > > 7 > > bits which you are limiting yourself to, my suggestion is to take > > something above 127 and below 256 as a special char. > > Most fun one would be “ÿ” which is a normal character you can pass on a > > shell script if you must, its actual byte-value is 0xFF > > Until some helpful application (shell or else) will try to interpret it > as UTF-8. Ehm, how would “some helpful application” manage to get in your qrexec policy-frameowork? If you fear that you have bigger issues as they could replace anything with anything... Anyway, to answer your fear. No. UTF-8 doesn't allow 0xFF, it will just tell you the stream is broken. (see attached example file) Or, more likely, it will just switch off utf-8. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/2513384.SI2geNoQLk%40strawberry. For more options, visit https://groups.google.com/d/optout. �b
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 5:15:08 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 08:08:54AM -0800, Yuraeitha wrote: > > On Tuesday, February 20, 2018 at 4:52:00 PM UTC+1, Marek > > Marczykowski-Górecki wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > On Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > > > > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > > > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > > > > Marczykowski-Górecki wrote: > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > > Hash: SHA256 > > > > > > > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > > > > After doing the most recent qubes-dom0-update from the testing > > > > > > > repository, all RPC calls from one VM to another stopped working. > > > > > > > Calls from dom0 still works fine. > > > > > > > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives > > > > > > > me a "Request refused". > > > > > > > > > > > > Have you updated also templates? If not, install updates also there > > > > > > and > > > > > > restart all the VMs. Details here: > > > > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > > > > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 > > > > > clone I've got. I've also tried debian-9 to debian-9 only. Same error > > > > > message across the board, in all 3 different templates. > > > > > > > > Apologies, fedora-26* not fedora-9. > > > > > > Looks like one more thing needs to be restarted: the tool handling > > > RPC calls confirmations: > > > > > > In dom0, as normal user: > > > > > > killall qrexec-policy-agent > > > qrexec-policy-agent >>~/.xsession-errors 2>&1 & > > > > It seems writing these commands solved half the problem? I now get the same > > error that Elias was talking about "Request refused" instead of the issue > > that it can't find the location. It's a pretty short message, just an > > outright permission denial. > > > > I got an odd feedback from the second command in dom0 though, maybe it's > > not normal? > > > > $ killall qrexec-policy-agent > > $ qrexec-policy-agent >>~/.xsession-errors 2>$1 & > > & not $ > > > [1] 16771 > > bash: $1: ambiguous redirect > > [1]+ Exit 1 qrexec-policy-agent >> ~/.xsession-errors 2> $1 > > > - -- > 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/THMrX1ywFAlqMSVsACgkQ24/THMrX > 1yyZigf+I/of4t9uufxPJd2bIe9GZB+B+U0GHaM7lsxXTe4ZUE+B8aw2kORpeB9K > JW2Yymvhwy1aT1xerfy0CZgk7pCCwddD9QUks+uapaxZ6gDi9eKu8FYN38W2nxu+ > ofLkmjOnMwXxs8rPTjjjZ9HKRScdBxHjDqUyiR7Vy4yYvYrIk3t+UvHYhYEBZ0VS > k9ly3yKSN3KombvPLtkUHzXHmsY0PW+CPlsmZ0Wv+K6b8EJEypshTtdbN0v1Ho1W > 7AwPwyS/a/SroGU6i1tCr7vR3CKb/FkyGjJm8MU0mcRUc57oGH+H1dic+tF3qPDg > eq1Wzmcdd0KUw1hGoHQAE7X2hQhWCg== > =QPhx > -END PGP SIGNATURE- Sorry about that. - I corrected my typo and ran both commands again, it now gives back a normal feedback in dom0. - The GUI copy to VM now works, but the terminal qvm-copy still doesn't work. - I did a full shutdown, then a start again. No changes, the GUI right click on file to copy to VM still works, but the terminal does not. - I attached a screenshot of how it looks when the terminal gives the error. It's the same error that came from before typing the 2 commands you gave. Correcting my typo returned the error message instead of the mentioned permission request. - I made sure to put the address correct, the one you can see in the screenshot, by drag and dropping the file, so that the path was auto-generated. There should therefore presumably be no typo's in the path address. It's also the same error from all the previous issues. -- 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/75cd4728-4041-44d2-a758-4d2119f4cdbb%40googlegroups.com. 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 Tue, Feb 20, 2018 at 08:08:54AM -0800, Yuraeitha wrote: > On Tuesday, February 20, 2018 at 4:52:00 PM UTC+1, Marek Marczykowski-Górecki > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > > > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > > > Marczykowski-Górecki wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA256 > > > > > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > > > After doing the most recent qubes-dom0-update from the testing > > > > > > repository, all RPC calls from one VM to another stopped working. > > > > > > Calls from dom0 still works fine. > > > > > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me > > > > > > a "Request refused". > > > > > > > > > > Have you updated also templates? If not, install updates also there > > > > > and > > > > > restart all the VMs. Details here: > > > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 > > > > clone I've got. I've also tried debian-9 to debian-9 only. Same error > > > > message across the board, in all 3 different templates. > > > > > > Apologies, fedora-26* not fedora-9. > > > > Looks like one more thing needs to be restarted: the tool handling > > RPC calls confirmations: > > > > In dom0, as normal user: > > > > killall qrexec-policy-agent > > qrexec-policy-agent >>~/.xsession-errors 2>&1 & > > It seems writing these commands solved half the problem? I now get the same > error that Elias was talking about "Request refused" instead of the issue > that it can't find the location. It's a pretty short message, just an > outright permission denial. > > I got an odd feedback from the second command in dom0 though, maybe it's not > normal? > > $ killall qrexec-policy-agent > $ qrexec-policy-agent >>~/.xsession-errors 2>$1 & & not $ > [1] 16771 > bash: $1: ambiguous redirect > [1]+ Exit 1 qrexec-policy-agent >> ~/.xsession-errors 2> $1 - -- 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/THMrX1ywFAlqMSVsACgkQ24/THMrX 1yyZigf+I/of4t9uufxPJd2bIe9GZB+B+U0GHaM7lsxXTe4ZUE+B8aw2kORpeB9K JW2Yymvhwy1aT1xerfy0CZgk7pCCwddD9QUks+uapaxZ6gDi9eKu8FYN38W2nxu+ ofLkmjOnMwXxs8rPTjjjZ9HKRScdBxHjDqUyiR7Vy4yYvYrIk3t+UvHYhYEBZ0VS k9ly3yKSN3KombvPLtkUHzXHmsY0PW+CPlsmZ0Wv+K6b8EJEypshTtdbN0v1Ho1W 7AwPwyS/a/SroGU6i1tCr7vR3CKb/FkyGjJm8MU0mcRUc57oGH+H1dic+tF3qPDg eq1Wzmcdd0KUw1hGoHQAE7X2hQhWCg== =QPhx -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/20180220161427.GD2084%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 Tuesday, February 20, 2018 at 4:52:00 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > > Marczykowski-Górecki wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > > > Hash: SHA256 > > > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > > After doing the most recent qubes-dom0-update from the testing > > > > > repository, all RPC calls from one VM to another stopped working. > > > > > Calls from dom0 still works fine. > > > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > > > > "Request refused". > > > > > > > > Have you updated also templates? If not, install updates also there and > > > > restart all the VMs. Details here: > > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 > > > clone I've got. I've also tried debian-9 to debian-9 only. Same error > > > message across the board, in all 3 different templates. > > > > Apologies, fedora-26* not fedora-9. > > Looks like one more thing needs to be restarted: the tool handling > RPC calls confirmations: > > In dom0, as normal user: > > killall qrexec-policy-agent > qrexec-policy-agent >>~/.xsession-errors 2>&1 & > > - -- > 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/THMrX1ywFAlqMQ+4ACgkQ24/THMrX > 1ywD6QgAg5XOhohAUNjHlAzL3Ua4jqaBG+5JsIyGkbmwiPYL928E+COvYG8WRf02 > 7v1oJZIxGo+cN6SehM7psg8xkAx/XLVBOgjF2dBz2dLfhg+JihX6s1qHeGDLnHwi > 4RSV8iHyqGp38S+ujcx6yuY2+ufNbNBR3WHg9pA+cufBUsHDTp+xm9ZY4e2KB4P9 > RQ9TufAE9W3511poSRXejtjKY+qKqIzWY5S2mGpe2wnUWma5Ps4lLmMaDezewoh6 > +TVY+vcolKh9ZbDGzhKNSon4FygvSB190OQjYa+i3MmK1tCtqSDm4vONKDABLqAA > gDUz/H0mF6AXd/JrwBMtVP8pjZAjDg== > =s3Eo > -END PGP SIGNATURE- It seems writing these commands solved half the problem? I now get the same error that Elias was talking about "Request refused" instead of the issue that it can't find the location. It's a pretty short message, just an outright permission denial. I got an odd feedback from the second command in dom0 though, maybe it's not normal? $ killall qrexec-policy-agent $ qrexec-policy-agent >>~/.xsession-errors 2>$1 & [1] 16771 bash: $1: ambiguous redirect [1]+ Exit 1 qrexec-policy-agent >> ~/.xsession-errors 2> $1 Written over exactly as it looks in the dom0, I'm not sure if it's meant to give this reply back or if this is normal. I'll do a new restart and more testing once I get off the road. -- 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/f565b3eb-730f-4b13-8b6c-7dfb12497f4f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Feb 20, 2018 at 04:27:16PM +0100, 'Tom Zander' via qubes-devel wrote: > On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > > 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. > > > > > > 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]) > [] > > 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. :) > > The thing you have to rememeber is that the escape character never needs to > be typed by the user. > In QRexec you are defining an API, applications like qvm-run are using that > API. What the user passes into qvm-run and what is actually sent to dom0 > does not have to be identical. In theory yes, but this would introduce more complexity to this code (taking care where which encoding is used etc). > I guess you do the translation currently as well; '$' turns into '@' in your > new code. > > The consequence of this is that you don't have to limit yourself to the > posix list. > Using the portable characters set for a non-character simply isn't needed. > > So, knowing that your API is actually based on 8-bit characters and not 7 > bits which you are limiting yourself to, my suggestion is to take something > above 127 and below 256 as a special char. > Most fun one would be “ÿ” which is a normal character you can pass on a > shell script if you must, its actual byte-value is 0xFF Until some helpful application (shell or else) will try to interpret it as UTF-8. - -- 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/THMrX1ywFAlqMRLUACgkQ24/THMrX 1yxCegf+Iii677oWd0CmJgoygfVfiQnmDl+a7XBX/i+tb8BMqO67AgwzoM6cWXq6 ZaA76a50qKSmcSjj6xSPtg4sPV0hqpgORsnxikAn5zg9vi7QJMJ0q+hKuKVxHAY1 TZSVFynTs6ci0JjgVRiB8QZCrl2eC9hQraGs46u6Zevvj80ZapaEqu0Sh0rowpDe SZ+QbiKi/QD1IeSF03OjnlqtoEyAZtPJ4dMY9F8IpR0P/vzsPxnkx/493HVjSA1i 7Z7kutdCcrGAqCtROhQ9DnS7+GTfdNcDJ5zwZ5yz5fJWlrzFgDSjENuwrSUqU/13 W6HNQVwx/fW+RBseUkJ/o98GHVW8sg== =af4O -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/20180220155436.GC2084%40mail-itl. 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 Tue, Feb 20, 2018 at 07:40:15AM -0800, Yuraeitha wrote: > On Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek > > Marczykowski-Górecki wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > > After doing the most recent qubes-dom0-update from the testing > > > > repository, all RPC calls from one VM to another stopped working. Calls > > > > from dom0 still works fine. > > > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > > > "Request refused". > > > > > > Have you updated also templates? If not, install updates also there and > > > restart all the VMs. Details here: > > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 clone > > I've got. I've also tried debian-9 to debian-9 only. Same error message > > across the board, in all 3 different templates. > > Apologies, fedora-26* not fedora-9. Looks like one more thing needs to be restarted: the tool handling RPC calls confirmations: In dom0, as normal user: killall qrexec-policy-agent qrexec-policy-agent >>~/.xsession-errors 2>&1 & - -- 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/THMrX1ywFAlqMQ+4ACgkQ24/THMrX 1ywD6QgAg5XOhohAUNjHlAzL3Ua4jqaBG+5JsIyGkbmwiPYL928E+COvYG8WRf02 7v1oJZIxGo+cN6SehM7psg8xkAx/XLVBOgjF2dBz2dLfhg+JihX6s1qHeGDLnHwi 4RSV8iHyqGp38S+ujcx6yuY2+ufNbNBR3WHg9pA+cufBUsHDTp+xm9ZY4e2KB4P9 RQ9TufAE9W3511poSRXejtjKY+qKqIzWY5S2mGpe2wnUWma5Ps4lLmMaDezewoh6 +TVY+vcolKh9ZbDGzhKNSon4FygvSB190OQjYa+i3MmK1tCtqSDm4vONKDABLqAA gDUz/H0mF6AXd/JrwBMtVP8pjZAjDg== =s3Eo -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/20180220155118.GO4302%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 Tuesday, February 20, 2018 at 4:38:26 PM UTC+1, Yuraeitha wrote: > On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki > wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > > After doing the most recent qubes-dom0-update from the testing > > > repository, all RPC calls from one VM to another stopped working. Calls > > > from dom0 still works fine. > > > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > > "Request refused". > > > > Have you updated also templates? If not, install updates also there and > > restart all the VMs. Details here: > > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > > > - -- > > 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/THMrX1ywFAlqMOWIACgkQ24/THMrX > > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > > =57Zw > > -END PGP SIGNATURE- > > Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 clone > I've got. I've also tried debian-9 to debian-9 only. Same error message > across the board, in all 3 different templates. Apologies, fedora-26* not fedora-9. -- 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/1f6c1248-017b-4492-ade2-3a6b9b3db3af%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 Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > After doing the most recent qubes-dom0-update from the testing repository, > > all RPC calls from one VM to another stopped working. Calls from dom0 still > > works fine. > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > "Request refused". > > Have you updated also templates? If not, install updates also there and > restart all the VMs. Details here: > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > - -- > 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/THMrX1ywFAlqMOWIACgkQ24/THMrX > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > =57Zw > -END PGP SIGNATURE- Just tested qvm-copy (terminal) on both debian-9 and another fedora-9 clone I've got. I've also tried debian-9 to debian-9 only. Same error message across the board, in all 3 different templates. -- 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/25c306fb-e22b-4e5a-a353-57ebc46bf448%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
I did update, and I am reasonably sure that everything was restarted after that. However, I will try again in the morning and report back. -- 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/b28e7408-e4df-4654-993f-3b65af6345a2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
On Tuesday, 20 February 2018 14:04:03 CET Wojtek Porczyk wrote: > 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. > > > > 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]) [] > 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. :) The thing you have to rememeber is that the escape character never needs to be typed by the user. In QRexec you are defining an API, applications like qvm-run are using that API. What the user passes into qvm-run and what is actually sent to dom0 does not have to be identical. I guess you do the translation currently as well; '$' turns into '@' in your new code. The consequence of this is that you don't have to limit yourself to the posix list. Using the portable characters set for a non-character simply isn't needed. So, knowing that your API is actually based on 8-bit characters and not 7 bits which you are limiting yourself to, my suggestion is to take something above 127 and below 256 as a special char. Most fun one would be “ÿ” which is a normal character you can pass on a shell script if you must, its actual byte-value is 0xFF -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/5355623.KmoKho9gXC%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 4:06:58 PM UTC+1, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > > After doing the most recent qubes-dom0-update from the testing repository, > > all RPC calls from one VM to another stopped working. Calls from dom0 still > > works fine. > > > > By "not working" I mean that the call to qrexec-client-vm gives me a > > "Request refused". > > Have you updated also templates? If not, install updates also there and > restart all the VMs. Details here: > https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt > > - -- > 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/THMrX1ywFAlqMOWIACgkQ24/THMrX > 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 > mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD > T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U > 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr > Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS > xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== > =57Zw > -END PGP SIGNATURE- I can verify that the computer on my end had the template updated yes, also full system restart by shutting down the computer, then starting again. Everything was updated before restart. Commands that was used, checked by opening terminal and arrow up in history: dom0: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing fedora-26: sudo dnf update --enablerepo=qubes-vm-*-current-testing It's not the issue this time, however I've experienced some issues with the update not going through properly where I had to run 'sudo dnf clean all' first before I could update. The first update today was like that too, but I believe I caught all of situations it happened in the different templates? I've seen it both in dom0 and in the fedora template. Upstream fedora dnf bug maybe? Time-span was last 14 days or so, but I'm not sure if it could have occurred longer back. I just did a clean all now again, no new updates was available afterwards. So I guess it isn't this cache 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/901559de-7dd6-44e7-bcfa-70a319f324c5%40googlegroups.com. 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 Tue, Feb 20, 2018 at 02:24:22AM -0800, Elias Mårtenson wrote: > After doing the most recent qubes-dom0-update from the testing repository, > all RPC calls from one VM to another stopped working. Calls from dom0 still > works fine. > > By "not working" I mean that the call to qrexec-client-vm gives me a "Request > refused". Have you updated also templates? If not, install updates also there and restart all the VMs. Details here: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-038-2018.txt - -- 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/THMrX1ywFAlqMOWIACgkQ24/THMrX 1ywCxAf/ad8xHLawtWPnwZxoBvc/ZT7PdfhOQjexUwcy03fRVDdvHUpSlAekfQ/2 mhdzxSyqYvZveeZkO3prKsEmYeNpG4bhOMXbh3cPqrcDS6jv7CAuQieaUlk1neyD T7P/3nSNU+Q/+eokXf40qg8rZhdHzz6JvY04lEg9kwkMD+jAHDZlzIJdeMb7ZJ6U 6ot9XUcYk+WC0a5FjzMHqRtDI9cTwzqqrgPMhp5bRANvLnyCdo7wL/m6C6s+yWKr Ny+p/18IoySwIz1+j6FMMRDU60YmFqKZlfqteHCIvxqwBdp+nSonQ6+SzehUF4bS xSU0Ff9LL6VOFLfjDdkz93gvRVY1Yw== =57Zw -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/20180220150618.GB2084%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working
[user@Study ~]$ qvm-copy Stream ~/LanguageTool.log qfile-agent: Fatal error: stat Stream (error type: No such file or directory) Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. EOF [user@Study ~]$ Not the kind of error message I was expecting, but it does look like it can't find the files. Since it was $ that was removed in the update today, which with my poor understanding of code, seems to be location related? Perhaps it's not a coincidence that qvm-copy can't find the location, a typo in the code perhaps? -- 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/1ffec98e-b11d-4912-934f-5f11050e65ab%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 3:37:54 PM UTC+1, Elias Mårtenson wrote: > I'm away from my computer at the moment so I can't try to reproduce all your > tests, but I did try to use copy-to-vm from Nautilus on a fedora-26 > template-based vm and it didn't seem to do anything. The menu just closed. > > I can't say if anything else in the Nautilus instance worked after that, as I > closed the window after that. It seems we both have the same, it would seem? It seems to behave slightly different, but the same bug by the looks of it. I found more odd behaviour after I decided to test a bit more. Used 2 different AppVM's, same template again. This time I used the terminal instead of the GUI, so nautilus was excluded in the equation. I did not know qvm-copy-to-vm/qvm-move-to-vm had been deprecated, the terminal told me just now. But funnily enough, the old deprecated qvm-copy-to-vm command worked just fine, while the new qvm-copy failed. I suppose the old deprecated qvm-copy-to-vm can be a short-term temporary solution if it's needed? If it's still there and not removed despite being deprecated, then I suppose it's still safe to use the deprecated version? - - - - - - Also, before I did any of the above, between my two posts here, I encountered a 10-12 seconds or so long system wide freeze, entire screen, all VM's, dom0, mouse, everything frooze. I've never had this before on this machine, and I've never seen it in Qubes 4. This was something very new, or so it seems at least. My laptop only has 8GB ram, so I guess it could be something related to RAM. But whether these two issues are related or not? I don't know. But it had never happened before today, and I've used this computer everyday for months, running Qubes 4 since RC-2. Could the RAM balancing between the AppVM's have been affected too, perhaps? -- 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/4d84619d-c2ff-4c66-9e14-1cdd2e709e9f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working
I'm away from my computer at the moment so I can't try to reproduce all your tests, but I did try to use copy-to-vm from Nautilus on a fedora-26 template-based vm and it didn't seem to do anything. The menu just closed. I can't say if anything else in the Nautilus instance worked after that, as I closed the window after 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/5df13ab4-d7cb-42a5-99e5-33e16127df1e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: Possible regression: vm-to-vm RPC calls stopped working
On Tuesday, February 20, 2018 at 11:24:22 AM UTC+1, Elias Mårtenson wrote: > After doing the most recent qubes-dom0-update from the testing repository, > all RPC calls from one VM to another stopped working. Calls from dom0 still > works fine. > > By "not working" I mean that the call to qrexec-client-vm gives me a "Request > refused". > > This includes calls to qvm-copy as well, since it uses the qubes.Filecopy RPC > call. > > Is this a known problem? > > Regards, > Elias I can semi-reproduce it yes, I was not aware of it before seeing your post though. -- Tested -- qvm-move-to-vm (worked fine) qvm-open-in-dvm (worked fine) qvm-copy-to-vm (failed with a freeze) -- Behaviour -- The File manager (Nautilus) froze when it failed. Nothing else stopped working in the AppVM, it was only Nautilus that frooze. I could stop the pending sending window, not a problem, but it probably kept pending since Nautilus frooze? Essentially it seems like this *bug* is causing Nautilus to freeze up. The target AppVM had no issues, it remained stable. -- Environment -- Target and receiving AppVM's had same template, Fedora-26. Updates on current-testing (both dom0 and template). Tested with GUI right clicking, did not verify with the terminal counterparts. Do you see the Nautilus freezing too Elias? or is this just my machine doing that? It seems qvm-copy-to-vm in Fedora is broken at least, since we both had issues with that one. -- 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/d5cc3c1f-b042-4d87-915b-186b2a71fd2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
-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- -- 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/20180220130403.GL1198%40invisiblethingslab.com. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
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? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/4514339.zi2rDXN2r4%40strawberry. For more options, visit https://groups.google.com/d/optout.
[qubes-devel] Possible regression: vm-to-vm RPC calls stopped working
After doing the most recent qubes-dom0-update from the testing repository, all RPC calls from one VM to another stopped working. Calls from dom0 still works fine. By "not working" I mean that the call to qrexec-client-vm gives me a "Request refused". This includes calls to qvm-copy as well, since it uses the qubes.Filecopy RPC call. Is this a known problem? Regards, Elias -- 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/9606becc-5c00-46c6-bb06-28ae90624a18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.