Re: [qubes-devel] Possible regression: vm-to-vm RPC calls stopped working

2018-02-20 Thread Elias Mårtenson 
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

2018-02-20 Thread Chris Laprise 
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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread 'Tom Zander' via qubes-devel 
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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread 'MirrorWay' via qubes-devel 
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

2018-02-20 Thread 'Tom Zander' via qubes-devel 
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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread Yuraeitha 
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] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread 'Tom Zander' via qubes-devel 
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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread Marek Marczykowski-Górecki 
-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

2018-02-20 Thread Yuraeitha 
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

2018-02-20 Thread Elias Mårtenson 
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.

Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak

2018-02-20 Thread Wojtek Porczyk 
-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

2018-02-20 Thread 'Tom Zander' via qubes-devel 
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

2018-02-20 Thread Elias Mårtenson 
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.