feature request
haaber
possible to reserve one of them exclusively for dom0 and templateVM
terminals -sort of a separated "admin screen"- to avoid other
appVM-windows popping up and being able to capture input from keyboard?
Bernhard
brenda...@gmail.com
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.
B
Claudia
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.)
Then, optionally you could implement some sort of policy to enforce which VMs are allowed to connect to which guid. Whether as a qubes-rpc policy of some sort, within guid, or just a simple X hook/script using the _NET_QUBESVM window property.
https://www.qubes-os.org/doc/gui/
https://www.cs.uic.edu/~xzhang/vchan/
https://github.com/QubesOS/qubes-core-vchan-xen
https://github.com/QubesOS/qubes-gui-daemon
PS: I can't believe the devs are actually thinking about rolling out GUI domains by default in 4.1. It's hard enough to get Qubes running on a given machine as it is now, let alone the fact that VGA passthru is a total crapshoot even under the best conditions. I still can't even get sys-usb to work without corrupting memory space of my VGA controller and SATA controller.
Claudia
> January 25, 2020 11:58 AM, brenda...@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.
Chris Laprise
under System Settings / Desktop Management / Window Rules. You can
specify how it matches the window, such as pattern matching on the
window title.
For example, if you set Window Title to 'Regular expression' and the
text to '^\[personal', then under Size/Position select 'Desktop', 'Apply
Initially' and 'Desktop 2' ... that will make windows from any VM
beginning with "personal" open only on Desktop 2. You can also use
'Force' instead of 'Apply Initially' and that will prevent you from
moving those windows to a different desktop.
I think the regular expression matching is probably powerful enough to
do what you want. For example, a rule for any window title NOT beginning
with '[' and NOT having also ']' would be a dom0 window. Another rule
could have the names of all your templates.
--
Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Claudia
> On 1/25/20 7:15 AM, haaber wrote:
>
>> Hello, I have several virtual screens; I guess many user have. Is it
>> possible to reserve one of them exclusively for dom0 and templateVM
>> terminals -sort of a separated "admin screen"- to avoid other
>> appVM-windows popping up and being able to capture input from keyboard?
>> Bernhard
>
> KDE lets you confine windows to certain screens or virtual desktops
> under System Settings / Desktop Management / Window Rules. You can
> specify how it matches the window, such as pattern matching on the
> window title.
>
> For example, if you set Window Title to 'Regular expression' and the
> text to '^\[personal', then under Size/Position select 'Desktop', 'Apply
> Initially' and 'Desktop 2' ... that will make windows from any VM
> beginning with "personal" open only on Desktop 2. You can also use
> 'Force' instead of 'Apply Initially' and that will prevent you from
> moving those windows to a different desktop.
>
> I think the regular expression matching is probably powerful enough to
> do what you want. For example, a rule for any window title NOT beginning
> with '[' and NOT having also ']' would be a dom0 window. Another rule
> could have the names of all your templates.
1) At least on my machine (XFCE), dom0 windows start with "[Dom0]". But I get your point.
2) The "[<vm>]" part of the window title is not actually part of the WM_NAME property. It's the WM_CLIENT_MACHINE property. But as long as you can match on that, it makes it even easier to write rules. You can see it with xprop:
[user@dom0 ~]$ xprop -id 0x1614d7d | grep -i 'Dom0'
WM_CLIENT_MACHINE(STRING) = "dom0"
WM_ICON_NAME(STRING) = "Terminal - user@dom0:~"
_NET_WM_ICON_NAME(UTF8_STRING) = "Terminal - user@dom0:~"
WM_NAME(STRING) = "Terminal - user@dom0:~"
_NET_WM_NAME(UTF8_STRING) = "Terminal - user@dom0:~"
Interestingly, I don't actually see a property equal to the full titlebar of the window, so I guess that's constructed by the window manager.
pixel fairy
pixel fairy
Michael Andersson
I'm using dwm on my everyday qubes thinkpads and it works great, all application windows goes there where I want them to go and they don't mess my currently active "window".
Lähetetty Jolla Sailfish -älypuhelimestani.
Alkuperäinen viesti
Lähettäjä: haaber
Lähetetty: lauantaina 25. tammikuuta 2020 13.15
Päättymisaika: qubes-users; Andrew David Wong
Aihe: [qubes-users] feature request
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1c4a6f80-6f85-f1c1-4995-dc5f0cb0ab2b%40web.de.
