Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-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
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
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
-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
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
Re: [qubes-devel] Design questions for the next steps of the Qubes shared folders service
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Dec 13, 2021 at 06:58:02AM +0100, Manuel Amador (Rudd-O) wrote: > Hi folks. > > I wrote the Qubes shared folders service in an afternoon. It is what it is > -- useful, but not ideal. > > I've come up with a design for an improved version that I would like you to > review for correctness and to see if it could be implemented better. I > think this design has potential, and I want your feedback before > implementing it. > > The document is at > https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md > — I am adding the contents of the document below. Please go ahead and > analyze it. Thanks in advance for your feedback. > # User interaction > > What we propose is the following: > > 1. The user instructs the client qube to mount folder `X` on the server > qube. > 2. dom0 asks the user "client qube wants to mount folder `X` on server > qube". > 3. The user responds accordingly. If authorized, the connection is > permitted and the client qube can successfully mount `X`. > > The Qubes policy argument mechanism is insufficient for the proposed > interaction. For one, it limits the argument size to 64 bytes This is no longer the case in Qubes 4.1: https://www.qubes-os.org/news/2020/06/22/new-qrexec-policy-system/#performance-improvements (the limit is now ~64k) > , making it > unsuitable for a wide possibility of paths the user might want to connect > to. Second, it doesn't actually convey the information that the client qube > sent — it conveys a form of hobbled information that crucially does not > include spaces, slashes, or other special characters, all of which are > legitimate in POSIX paths. There are ways around it - encode the path. We do that for qubes.VMExec service for example: https://www.qubes-os.org/doc/vm-interface/#qubes-rpc This way, the argument itself is still safe to process in various tools (even log4j :P), and represents almost friendly path - /home/user/Work/project-X would become -2Fhome-2Fuser-2FWork-2Fproject--X. > Third, the way that the question is presented is > not exactly usable. This is indeed a problem, especially the user would see only a mangled path, and no info that the thing is indeed the path... This could be solved with https://github.com/QubesOS/qubes-issues/issues/5853, but that exists only in plans now. > # Implementation details > > The circumstances lead us to consider the implementation of an alternative > security mechanism, proposed here. (...) 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. 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... - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmG4qfIACgkQ24/THMrX 1yy3Ywf7BE7xOcqzMdSgn4Un3SZkokDMBaoN0Rr2EQ5pNLPgM9SUI9NEnvJ+TEZ7 xLTvNpRiYWSkjmVXsfUJrCZmQ+0NEvifiay4xWP0g/paYfRaL9Pa2vMOtHMv2Ncv vcE0T01bCrek/0BPJfsQI1n27zaZdUwIz4o3sJofzRoocMBk7Kq0x6jC/Gw35Qkh xi42R7XcDutPwuRi5JZKTBxfH7hVIKkizEIEUsN7qe0Fn80nfhRvdIi6VgJb+Wz2 3cJ38oiMBQg46OQ256J1viMZaKz+H4hyDWtTJcCzLcu9mImr+tkdIVHTFrBNMjbF QRmSGRsAV3LuScjUGCTIYDAV3A6qmA== =OcxO -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/Ybip8vY29iVo3cY4%40mail-itl.
[qubes-devel] Design questions for the next steps of the Qubes shared folders service
Hi folks. I wrote the Qubes shared folders service in an afternoon. It is what it is -- useful, but not ideal. I've come up with a design for an improved version that I would like you to review for correctness and to see if it could be implemented better. I think this design has potential, and I want your feedback before implementing it. The document is at https://github.com/Rudd-O/qubes-shared-folders/blob/master/doc/authorization-design.md — I am adding the contents of the document below. Please go ahead and analyze it. Thanks in advance for your feedback. - # Next-gen folder share authorization design Initially, Qubes shared folders used standard Qubes RPC authentication to decide whether to grant access to the folders of a qube (called *server* in this document) initiated by another qube (called *client* in this document). This happens through the client qube invoking the `ruddo.ShareFolder` RPC service on the server qube, which if successful causes the `diod` daemon to be started on the server VM and finally connected via file descriptors to the kernel `v9fs` file system module in the client VM. This is perfectly adequate for the use case where the user wants to grant the client qube blanket read/write access to any folder in the server qube. This is, however, inadequate if the user wants to grant different client qubes finer-grained access to specific subfolders. Consider, for example, one scenario of a "file server" qube that acts as a repository of data for three other client qubes: `work`, `projectX` and `social`. Our stipulated user may want to save some types of data to some folders in the file server qube, but may not want to mix them. In this scenario, our user wants work data to be saved to `fileserver:/home/user/Work`, social data to be saved to `fileserver:/home/user/Memes`, and his project X (work-related) involves some data that should *also* be accessible to his work qube, but he does not desire to grant the project X workspace access to *all* the work data, so he decides to store project X data under `fileserver:/home/user/Work/projectX`. We further stipulate in this scenario that shuttling files around manually using the `qvm-move` facilities would severely impede the user's enjoyment of the Qubes system he is running. This setup naturally requires a more sophisticated access control mechanism than a simple yes/no policy decision. # User interaction What we propose is the following: 1. The user instructs the client qube to mount folder `X` on the server qube. 2. dom0 asks the user "client qube wants to mount folder `X` on server qube". 3. The user responds accordingly. If authorized, the connection is permitted and the client qube can successfully mount `X`. The Qubes policy argument mechanism is insufficient for the proposed interaction. For one, it limits the argument size to 64 bytes, making it unsuitable for a wide possibility of paths the user might want to connect to. Second, it doesn't actually convey the information that the client qube sent — it conveys a form of hobbled information that crucially does not include spaces, slashes, or other special characters, all of which are legitimate in POSIX paths. Third, the way that the question is presented is not exactly usable. # Implementation details The circumstances lead us to consider the implementation of an alternative security mechanism, proposed here. Instead of directly contacting the server qube, the client qube will contact dom0 instead, through a special service `ruddo.AuthorizeFolderAccess` (with a default `allow` policy targeted at dom0), requesting access to a specific path of the server qube (id est, two arguments, the requested path and the target qube). The data mentioned will of course be sanitized accordingly, and rejected if they do not conform to a canonical form. dom0 can then pop up a dialog explicitly designed for the purpose of allowing this policy decision. This dialog will display the crucial information the user needs to know in order to make an informed decision: 1. The origin qube of the request. 2. The target qube of the request. 3. The folder it wants to request. 4. Whether the access should be one-time allow or always allow. If the user accepts this, then the decision data will be stored in dom0, on a dictionary keyed by the first 64 characters of the SHA256 hash of (origin, target, folder) — we will call this hash the decision fingerprint. Then dom0 will create (much like `policy.RegisterArgument` does today) a policy `allow` element (based on the decision the user made) that permits the client qube to access the server qube's `ruddo.ConnectToFolder` service (in charge of establishing the `diod` server-side of the file share service) but *only when the correct argument is supplied*. The decision fingerprint will then be returned to the client VM. At this
