Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service

2021-12-15 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Dec 16, 2021 at 01:27:43AM +0100, Manuel Amador (Rudd-O) wrote:
> On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote:
> > Here is how qrexec policy prompt is doing it:
> > https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112
> 
> Bad news, I did not understand any of that code. :-(
> 
> Just to see if I understand at least the process:
> 
> 1. dom0 sends RPC `policy.Ask` to GUIVM
> 2. this policy program pops up a dialog
> 3. the response comes back

Yes, exactly.

> If this is correct, please let me know if my following theory is correct:
> 
> 1. I create a `policy.AskBlah` policy with the same config as `policy.Ask`

Since it's dom0 who make the "policy prompt" call, you don't need a
policy for it.

> 2. I move my program that asks via UI to the package to be installed in
>the GUIVM

Yes.

> 3. I also move my RPC service code to that package

You mean the ruddo.AuthorizeFolderAccess service? No, that stays in
dom0.

> 4. I make my dom0 RPC that (today) executes the GUI program, invoke the
>policy.AskBlah service, and await a response

Yes.

> If so, how do I distinguish between the case of GUIVM and no GUIVM? 

You check for the source domains's "guivm" property. If it's "dom0", you
call `/etc/qubes-rpc/policy.AskBlah` directly, otherwise you call it via
qvm-run.

> Additionally, what about the folder share manager application?  It currently
> runs in dom0 (kinda has to, because dom0 is where the file share policy is
> stored).

Yes, I guess it should remain in dom0 in this design.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6ir8ACgkQ24/THMrX
1yzVWQf/Q9To2pFR5hATlzRGzYjXyhSVvzG+P0joXitkc+rbZ7T6gAlwkwRqNm2L
ZQzxQgkAlUZ+xOvGv2w1nE+sxwHd5c5cvAe8WKnIA6oiEUnfN+y5MDuK7iBCUMGB
ZAtkcVynomXYiNhLwUw+4EYuNKSeWMcVWH18RhChVp99XXfkr3kWlzjofGe1VCNK
+660MsfMlmw3whZegzpQ7sYFfF1TGSoojKKUwrrSmWEoImR0YPpabmOwQGWV0rQl
KYmQOUYuYmQiBx8T/J+bCp5YnOAfJnGIUw1AHMgKbubSQN6lqnMHwOgHXoWOo9mv
f5NMsiLv9SLrRMarFLsC/TobHB7RJA==
=C9IM
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/YbqKwH6Dd0ZgMdlU%40mail-itl.


Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service

2021-12-15 Thread Manuel Amador (Rudd-O)

On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote:

Here is how qrexec policy prompt is doing it:
https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112


Bad news, I did not understand any of that code. :-(

Just to see if I understand at least the process:

1. dom0 sends RPC `policy.Ask` to GUIVM
2. this policy program pops up a dialog
3. the response comes back

If this is correct, please let me know if my following theory is correct:

1. I create a `policy.AskBlah` policy with the same config as `policy.Ask`
2. I move my program that asks via UI to the package to be installed in
   the GUIVM
3. I also move my RPC service code to that package
4. I make my dom0 RPC that (today) executes the GUI program, invoke the
   policy.AskBlah service, and await a response

If so, how do I distinguish between the case of GUIVM and no GUIVM?  
Additionally, what about the folder share manager application?  It 
currently runs in dom0 (kinda has to, because dom0 is where the file 
share policy is stored).


--
Rudd-O
https://rudd-o.com/

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/5d7c05b3-3740-5cbc-e22b-7d0cd161cb03%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service

2021-12-15 Thread Manuel Amador (Rudd-O)

On 16/12/2021 01.07, Marek Marczykowski-Górecki wrote:

If going with standard qrexec prompt (+#5853), you'd get that for free;)
Otherwise, you need a qrexec service that calls into GUI domain to do
the prompt (and then validate its output to really allow only the thing
that was asked about, not something else). Basically, factor out the
prompt code into separate file, then call it via `qvm-run --service ...`
instead of directly.
Here is how qrexec policy prompt is doing it:
https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112


This is very useful, and the best news there is, is that the program 
that does the asking, is already completely factored out, and its 
inputs/outputs are filtered too.  Thank you.


--
Rudd-O
https://rudd-o.com/

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/531a7407-724c-3af3-a5a4-2f95100ac088%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service

2021-12-15 Thread Marek Marczykowski-Górecki
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Dec 16, 2021 at 12:17:44AM +0100, Manuel Amador (Rudd-O) wrote:
> Prefacing this response with:
> 
> I went with the implementation as designed by the document.  In the future I
> will revise argument passing to use the new 4.1 style, instead of base64
> over pipes. Currently the implementation uses a custom-made dialog — a very
> nice one, if I do say so myself — in the spirit of the feature request
> #5853.

:)

> On 14/12/2021 15.28, Marek Marczykowski-Górecki wrote:
> > I think it looks ok. Regarding one-time access, I'd rather specify it
> > with a timeout, to avoid cases when the client VM requests authorization but
> > uses it much later.
> 
> This will land in the project's to-do list and will be implemented at some
> point in the future.  Patches always welcome!
> 
> > 
> > One thing you may want to consider is interaction with GUI domain - in
> > this case dom0 couldn't directly ask the user, but rather ask the GUI
> > domain to display the prompt. We do this for normal policy prompts.
> > Anyway, it's of course up to you whether you support GUI domain or
> > not...
> 
> Yes, I intend to support the GUI domain. *How do I do this?* Right now my
> code merely spawns up, from dom0, a GUI dialog using DISPLAY:=0.  This was
> lifted from other parts of the Qubes repositories.

If going with standard qrexec prompt (+#5853), you'd get that for free ;)
Otherwise, you need a qrexec service that calls into GUI domain to do
the prompt (and then validate its output to really allow only the thing
that was asked about, not something else). Basically, factor out the
prompt code into separate file, then call it via `qvm-run --service ...`
instead of directly.
Here is how qrexec policy prompt is doing it:
https://github.com/QubesOS/qubes-core-qrexec/blob/master/qrexec/tools/qrexec_policy_exec.py#L64-L112

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG6g08ACgkQ24/THMrX
1yyy/wf+MP+ZLD3cgBPZivLwOaIyZGWn6I/nmaCEQnmjv6xnUw/gp37fEJIaDn1p
olyP4egGDSb0pDgf9F2JUfPNX9iO59AUdmxkq7tuQWNzP/Hp8vtcFR3vzS4Sug9H
TCW40s4KR3YMRR/I2icTe8KvuCqYrt7gE2WEFxuQ256OJtUM5VTfHZaEX4iy6MU9
P568+i34F7IEmj4p9ZvYAQBDgZXiuFCDi5Xo37Ma5U9kG8SQEwiPS9q5PTNkF065
N3sQqW+J1XDAIZRa2fAGnKcRwAFFm9Xdnap3JhaoiWlk5CaSJLWinLD/qH9WEbo7
/swlVqBnPt0uc/tWjuOi1UAt4dw7Ew==
=yfj2
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/YbqDTxMnZI5DINZi%40mail-itl.


Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service

2021-12-15 Thread Manuel Amador (Rudd-O)

Prefacing this response with:

I went with the implementation as designed by the document.  In the 
future I will revise argument passing to use the new 4.1 style, instead 
of base64 over pipes. Currently the implementation uses a custom-made 
dialog — a very nice one, if I do say so myself — in the spirit of the 
feature request #5853.


On 14/12/2021 15.28, Marek Marczykowski-Górecki wrote:

I think it looks ok. Regarding one-time access, I'd rather specify it
with a timeout, to avoid cases when the client VM requests authorization but
uses it much later.


This will land in the project's to-do list and will be implemented at 
some point in the future.  Patches always welcome!




One thing you may want to consider is interaction with GUI domain - in
this case dom0 couldn't directly ask the user, but rather ask the GUI
domain to display the prompt. We do this for normal policy prompts.
Anyway, it's of course up to you whether you support GUI domain or
not...


Yes, I intend to support the GUI domain. *How do I do this?* Right now 
my code merely spawns up, from dom0, a GUI dialog using DISPLAY:=0.  
This was lifted from other parts of the Qubes repositories.


--
Rudd-O
https://rudd-o.com/

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/ad26346a-6a2f-46fd-3113-76371a475dc9%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-devel] ANN: qubes-shared-folders 0.1.0, now with folder share manager

2021-12-15 Thread Manuel Amador (Rudd-O)

Hello, folks.

A new version of Qubes shared folders has been released.

https://github.com/Rudd-O/qubes-shared-folders

The main highlight of this version is a revamped security model that 
allows the user to securely delegate folder access permissions to 
specific pairs of qubes, either as a one-time basis, or permanently.  
The UI aims to be clear and easy to use. The included folder share 
manager allows the user to revoke or revise permanent share decisions 
any time after the fact.


Secondary highlights include a complete implementation of type checking, 
to prevent security issues and other common bugs that Python programs 
often carry.


Enjoy, and don't forget to open bugs if you find any.

--
Rudd-O
https://rudd-o.com/ 

--
You received this message because you are subscribed to the Google Groups 
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-devel/fd5dd640-e416-0824-1aff-0691e3e5b3f9%40rudd-o.com.


OpenPGP_signature
Description: OpenPGP digital signature