January 25, 2020 1:40 PM, "Claudia" <claud...@disroot.org> wrote:
> January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > >> I think some window managers allow one to pin certain applications to >> particular virtual desktops. >> But those aren’t really security features, more just window manager tricks >> to help users organize >> windows. >> >> My preference would be something along the lines of support for allowing >> multiple local x-servers >> in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and >> guests/domUs each or >> in groups to a particular x-server. Certain features would not work across >> x-windows sessions, e.g. >> inter vm copy/paste. One could also enforce it at the qubes policy level >> (e.g. no qvm-copy either). >> >> Useful if you want to reduce the chances of mistakenly leaking data across >> client work and/or >> personas. > > It seems to me like you could almost do this today, by starting another X on > another TTY each with > its own qubes_guid, optionally as different user. Each guid could probably be > patched* to listen on > different vchan "ports" (libvchan_[server|client]_init()), however I don't > think the vchan > infrastructure has any kind of real access control below the VM level. So in > order to really > isolate them on the dom0 side, you'd probably have to run a separate > xenstored for each X server, > so that you could control which server has access to the xenstore device > node. But I don't think > that would really be necessary if you're just trying to prevent accidental > leakage by the user. > > (*Currently it appears to use a hardcoded vchan "port" of 6000. See > qubes-gui-daemon/xside.c, and > qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is > actually the server, and > guid (dom0) is actually the client.) > Actually, what was I thinking. If the VM is the server and dom0 guid is the client, they wouldn't have to use different ports, assuming the vchan semantics works like TCP/IP. You'd just have to come up with some way to control which domains can send MSG_CREATE requests to which instance of guid. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ef06df5178ac410b480ddae583002b04%40disroot.org.
