-----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.
