Is there any hope for Wayland?

[Dima Puntus]

Hi,

After testing Qubes for a few weeks (3.1, 3.2-rc1,2&3), here's my 2 cents:

It's a great OS in many aspects but still unusable outside of the small group of the "terminal only" ppl. Reason # 1 is graphics. In this day and age it's expected for any OS to at least have basic video rendering without glitches. AFAIK, Qubes is still using the old Fedora 20 video drivers (even for Intel IGPs), while Fedora 25, Wayland enabled is only 2 months away. I thought this was a Xen+Fedora limitation, so I installed Fedora 24 + Xen, Ubuntu 16.04+Xen, Debian 8 + Xen, - and they all work ok with decent drivers. So, I guess, in order to conform to certain security requirements, the Qubes team was forced to "tweak" the X server and/or drivers.

So what's the current status on video drivers in Qubes? Is Wayland on its way or are we hooped? Any insights? This is not just my personal question (though I'd love to switch to Qubes as my primary OS) but also many of my colleagues in the IT/IS world. 

Thank you! 

[Jeremy Rand]

Dima Puntus:

> AFAIK, Qubes is still using the old Fedora 20 video drivers (even
> for Intel IGPs), while Fedora 25, Wayland enabled is only 2 months away.

AFAIK Qubes 3.2 is using Fedora 23 for dom0, meaning the video drivers
should be the same as what's in Fedora 23.

Cheers,
-Jeremy Rand

[pixel fairy]

wayland is inevitable. for the vms, this would take the form of a qubes compositor.

that said, ive used the gimp, watched movies, even toyed with video editing on a 6 year old laptop running qubes 3.2rc3. also played a bit with blender and it seems fine, but havent tried animating yet.

if your primary purpose is art/media i would not use qubes. maybe its ok if thats 2d / light3d. i think video editing should be fine, but id be iffy about high res compositing.

in the mean time, you can take a few ideas from qubes. i use vmware-fusion(virtualbox does not support nested virtualization) on my work computer, a macbookpro. all my work is done within virtual machines, most of which run linux. one runs os x, and i also have a vagrantbox of os x for development. all of them are generated with packer and controlled with ansible.

theres a special vm called "canary" that gets all the usb devices. it would also be possible to make a network vm to further isolate os x. (you can download updates offline) another special vm is called "vault". the only difference is the script types into the target vm instead of paste, because you can use firejail to protect apps from reading each others keystrokes, by giving all the apps their own x server. clipboard and fileshare is disabled in all the VMs, but i still dont want different apps within a vm reading each others keystrokes.

if your going this route, lookup sandbox for os x or firejail for linux. linux + kvm would be better than this vmware nonsense. i plan on trying that with fedora 25.

[Vít Šesták]

Video drivers AFAIK differ in those three versions:
3.0 seems to have Fedora 20 drivers
3.1 has some updated drivers, despite being based on Fedora 20
3.2 is based on Fedora 23

However, I can see little-to-no benefits of Wayland for Qubes:

In dom0, it might be some differences in GPU support. This is probably the main (dis)advantage at the moment. I believe that Wayland will come there when dom0 (or maybe GUIVM in future) is upgraded to corresponding version of Fedora. It will probably require some changes to some scripts and patches for Xfwm. KWin patches seem to be X11-agnostic.

In domU (AppVMs), I don't see any difference except having to port GUI forwarding mechanism.

Non-advantages or dubious avdantages in Qubes:

Acceleration support:
In dom0, GPU acceleration seems to be mostly supported today. Moreover, it does not seem to be needed much there, because it would be used mostly (and maybe only) for Window manager effects if enabled.
In domU, there is a different issue with graphic acceleration: it is not supported by Qubes at all, for security reasons. There might be some progress in the future (probably either second GPU pass-through or Intel HW GPU virtualization), but none of them seems to be connected to X11/Wayland dilema.

Security: Qubes brings a different isolation approach. Well, Wayland might make some intra-VM attacks more difficult, but it would be probably much work to make some reasonable mitigation.

A side note on firejail: I don't consider this as a true sandbox. It might be an useful tool for hardening against less severe exploits or some mitigation technique against firejail-unaware attackers, but an untrusted or RCEd application with firejail-aware attacker seems to be able to escape the "sandbox" by many ways. At least unless a very restrictive (non-default) policy is applied.

Regards,
Vít Šesták 'v6ak'

[Lorenzo Lamas]

Imo a good reason for Wayland in Qubes(Dom0 at least) is because x11 lockscreen is not secure.

[Vít Šesták]

This one might be the best reason for Wayland in Qubes, provided that Wayland is better.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2016-09-12 06:06, Lorenzo Lamas wrote:
> Imo a good reason for Wayland in Qubes(Dom0 at least) is because x11
> lockscreen is not secure.
>

Are you referring to this?

https://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/

If so, I see your point, but I don't think this is as serious of a
problem on Qubes as it is on other systems. Brief summary of points
from the blog post and responses:

Screen lockers on X11 cannot be secure because they...

1. Can be prevented from starting.

Since the screen locker runs in dom0, and only trusted programs run
in dom0, this will never happen maliciously in Qubes (unless dom0
has already been owned, in which case it's already game over).

2. Can be spoofed.

VMs cannot enter fullscreen mode without user permission, so a
fake screen locker in a compromised VM cannot successfully
spoof the real locker in dom0.

3. Cannot prevent other windows from grabbing screen content.

Qubes' GUI isolation prevents exactly this, regardless of whether
the screen locker is active.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX15BuAAoJENtN07w5UDAwMKAP/i6EAU22/mrGf8gBYFUQ0135
GjcttQPR/BgortZEYOFAYCDpBc1R5jx3VIgXe8yCMnlLKsh927S0dKpayfWHxfkT
yLHl+N/hah/suKu/Mh5J5skXpbOuvS5xzHeQRjMvxAMQrD5w0Q8nrZ/fR+LHHKK7
GvAGuJQeL8yIPdqda2dj+4IyBNGJE+txtmg5NQ9/a5WnyRDIEaGBOflLVIOQRdoC
YjOw9P2+c53xNqq3N1o/fYeUl0i/OZJVkwmperuJt8UxbNvq/9jUOFhxdOTQoJRX
Laqjd2vRGrG6wcTFrrb8aernM0HPUqYzcP/mXTiWWts0JHzmETz3rANTqNPD5Ka4
DfnbvpbEHSVz6jHuHSVPayCoBzVzGfv/DhFCxeKcqkDVRANhjdpJlWi3wLScK8GD
vrnrwpVvmuXLgXoMJmoCsuOSIwO1h2WBvwqeZT5sWQBsuJo7BVLxe+eDSpH9ZHg4
8llWfgYkXEbZwN95VYsskgtAGj5F1zPNLJD/iCXmPIwejbCsZtCu7YNjBlL5ggZ+
ca7J4Bf43BvBG6YL36xqLBHSA4Gz7CqhLvyRiQBZf1AOq46fcg0WuJgNp/njk/jf
QrfKpX7QFuC6uy3bvasZ8EW8at5xiUHGvdmT6MG20xI7+47bwKSipoWpvONKhFfG
1xAaZakVQ1ISCMmNP+ka
=MZHx
-----END PGP SIGNATURE-----

[Vít Šesták]

Well, the points you have mentioned are also dubious for mainstream Linux environment, not only for Qubes, because they suppose a malicious app already installed in the system.

Other point are, however, accidental interferences with lockscreen. For example, I sometimes see Thunderbird popup on the lockscreen. I don't consider Thunderbird to be a malicious app (if it was, it would probably send my emails via Internet, which would be more practical), but it still leaks few information. There are also some complaints by other users, see discussions about Physlock (which might be also a way to address these problem).

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

We should be careful to distinguish the claim that X11 screen lockers
*cannot* (even in principle) be secure (e.g., due to inherent
architectural limitations) from the claim that most (or even all)
*existing implementations* of X11 screen lockers are flawed, buggy,
or insecure.

Your and others' (legitimate) gripes about the screen lockers we
currently use are evidence of the latter (but not necessarily the
former) claim.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX15c7AAoJENtN07w5UDAw12oP/ihA/AfRA/y6C6Zd9pAiA078
Lk6HiaRr5AyMEsD9jDkE/wXYzKTWXbz1g6aRsjsQHmkCDG4mFd7gahKtm8ipGTPe
OFLGqaKjBu+e7eJLebd11DAT4iuQxa02rz2+c99dNXKZtf5RszDK6BMPhakq7PMY
G6oD1A4jyq0X78sKKTBWCgg2kkMe0mQVogWThXo5rLCjD/yqREAG6WDn7Q+no8R/
FvCd6FrbsrVFdLgO/W4g9ovvec1Wi5Fy3Cgx1iruW1t9ARSeYLuCT3FAeNdmtOUx
FhJvbpYdwc/GlFUSE9p1Xc7YYiBH2VATr26R7vBa9B4IABtymdVYJ9ifM3IuY9SN
bbCOCFQcmgH971DFN/Tou6qKD26PMMP6ovX8QnxpEX48irqlQl5Od3TN0FZORgVf
4VV5mB3jQ0+qoiLHJsEi8tjJUrfbnCbBArzw/ABFAoDEoeX00iPfpogR+ZplRjpN
WuXDmEUo8fp/SCgtk8rFVoFbeTSzTXgan8roQ0fKo6IiHLylm8esojzzyXUsK2Ss
Hh3OHsq+zORZxMqrvHP6JgkL4sd263ez41ds685zCWvMSq1IUwSlVXq3EMDPx5GH
pVgSrtwnHM3kNOALPBgNaw80HGsnhAWqz2OFTfxFZ1W4T1dLwji+P6FcjK96rPI4
E4ANXZRzxWj9vvL8CQLA
=ubMd
-----END PGP SIGNATURE-----

[pixelfairy]

On Sun, Sep 11, 2016 at 1:13 AM Vít Šesták <groups-no-private-mail--con...@v6ak.com> wrote:

Video drivers AFAIK differ in those three versions:
3.0 seems to have Fedora 20 drivers
3.1 has some updated drivers, despite being based on Fedora 20
3.2 is based on Fedora 23

However, I can see little-to-no benefits of Wayland for Qubes:

In dom0, it might be some differences in GPU support. This is probably the main (dis)advantage at the moment. I believe that Wayland will come there when dom0 (or maybe GUIVM in future) is upgraded to corresponding version of Fedora. It will probably require some changes to some scripts and patches for Xfwm. KWin patches seem to be X11-agnostic.

thats the next version, fedora 25. of course, x11 isnt leaving the distribution anytime soon, and even if xorg stops shipping, those qubes-vm tools will use xwayland until they're ported. 

 

In domU (AppVMs), I don't see any difference except having to port GUI forwarding mechanism.

Non-advantages or dubious avdantages in Qubes:

Acceleration support:
In dom0, GPU acceleration seems to be mostly supported today. Moreover, it does not seem to be needed much there, because it would be used mostly (and maybe only) for Window manager effects if enabled.
In domU, there is a different issue with graphic acceleration: it is not supported by Qubes at all, for security reasons. There might be some progress in the future (probably either second GPU pass-through or Intel HW GPU virtualization), but none of them seems to be connected to X11/Wayland dilema.

Security: Qubes brings a different isolation approach. Well, Wayland might make some intra-VM attacks more difficult, but it would be probably  much work to make some reasonable mitigation.

agreed in that qubes solves most of the problems wayland does. the most visible issue wayland has over qubes-x11 is keyboard sniffing. you can  run all your gui apps in their own VM to avoid this, but thats more overhead than should be nessescary. 

i really dont like sensitive information touching a clipboard, which is why, on my mac, passphrases from the vault vm are typed into the target vm instead of pasted. (that, and theyd then have to be then copied to the xephyr instance, making it another step)

 

A side note on firejail: I don't consider this as a true sandbox. It might be an useful tool for hardening against less severe exploits or some mitigation technique against firejail-unaware attackers, but an untrusted or RCEd application with firejail-aware attacker seems to be able to escape the "sandbox" by many ways. At least unless a very restrictive (non-default) policy is applied.

RCEd?

if you know of something better than firejail, id like to look at that. ive looked at the old redhat selinux sandbox. havent looked at oz, from subgraphos yet.

the firejails issues page on github doubles as a discussion forum where we discuss these escapes, and there still a few known possible. i run mine with private-homes for all the firejailed apps, and that works pretty well (work computer, not qubes). you have to move files, for example from one browsers home, to your gimps home, but if your used to qubes, your doing that anyway. 

i think anyone sensibly security conscious would make better profiles. the default browser ones are pretty open, but the private home takes care of most of that. the defaults do change when people bring them up. a recent addition in the just released current version is blocking the ssh-agent socket in the default profile.

things still not handled include

* dbus (unless you have apparmor)

* microphone, unless you disable sound completely. qubes solves this. firejail also has issues with pulseaudio.

* X11 on not x11 apps unless you either disable network, or run the xserver without abstract sockets.

firejail cant yet block abstract sockets without also blocking the network.

 

Regards,
Vít Šesták 'v6ak'

--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/TyRFlTQnLeg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/32659041-852c-4e77-88d8-b1b6495b8e27%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Manuel Amador (Rudd-O)]

There was a problem getting Xen to compile in Fedora 24. Search for
those words in the mailing list.

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

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

AFAIR this particular problem was fixed (not sure if in xen 4.6 or 4.7).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX/jy2AAoJENuP0xzK19cspcwH/jxzJhzH866ebVh3OevNTDpU
mPs0eIg8K5z2bELh16FO40bIGQ0i6nVUxqhaWwHkp+2EKK6CLQ7kqOFC2I9qG3lP
eeBPqLVa9wSzc9Eblmf5qMoKz0zn0DaJH9/A+YrLO77vu9gV9D7su2naQoEz8nV8
SEF17jePb4O7Q3ot/Bzh0aATh12nBTIhjnBUUXlkyWi9r9OVan6C9TE7riHu/skt
iSeqDBdFZwU16Tn4W6EEBOvNghD3r/KYv4ZGUDcbxFX9oq5KWN1Pw8xMzfhyhDlv
dYPkmSXKqVektHY8K/8CEb/hzzczwKXnlwcc6UlvmvuqCmEQM6BCKG+pwheglNc=
=+Iva
-----END PGP SIGNATURE-----

[Manuel Amador (Rudd-O)]

On 09/13/2016 05:52 AM, Vít Šesták wrote:
> Well, the points you have mentioned are also dubious for mainstream Linux environment, not only for Qubes, because they suppose a malicious app already installed in the system.

They do not presuppose that. They merely presuppose an app has been
compromised by an attacker. This presupposition is valid in mainstream
Linux, and invalid in Qubes dom0. See the difference?

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

[Manuel Amador (Rudd-O)]

On 10/12/2016 01:38 PM, Marek Marczykowski-Górecki wrote:
>
>
> AFAIR this particular problem was fixed (not sure if in xen 4.6 or 4.7).
>

Is there support for upgrading dom0 to Fedora 24?

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

[Alex]

On 10/12/2016 06:04 PM, Manuel Amador (Rudd-O) wrote:
> On 10/12/2016 01:38 PM, Marek Marczykowski-Górecki wrote:
>>
>>
>> AFAIR this particular problem was fixed (not sure if in xen 4.6 or
>> 4.7).
>>
>
> Is there support for upgrading dom0 to Fedora 24?
>

The main problem is, does the qubes-gui facility support Wayland?

--
Alex

[Manuel Amador (Rudd-O)]

F25 will let X clients such as GUID on dom0 connect transparently to
Wayland via a local X server blitting to Wayland.

As for the domU side, I do not know but I presume clients shipping in
F25 all can detect whether to use X or Wayland based on their environment.

This is yet to be tested.

>


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

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Oct 12, 2016 at 07:55:54PM +0000, Manuel Amador (Rudd-O) wrote:
> On 10/12/2016 04:05 PM, Alex wrote:
> > On 10/12/2016 06:04 PM, Manuel Amador (Rudd-O) wrote:
> >> On 10/12/2016 01:38 PM, Marek Marczykowski-Górecki wrote:
> >>>
> >>> AFAIR this particular problem was fixed (not sure if in xen 4.6 or
> >>> 4.7).
> >>>
> >> Is there support for upgrading dom0 to Fedora 24?

No. But if you really like, you can try building it yourself (set
DIST_DOM0=fc24 in builder.conf).

> > The main problem is, does the qubes-gui facility support Wayland?
>
> F25 will let X clients such as GUID on dom0 connect transparently to
> Wayland via a local X server blitting to Wayland.

I *guess* dom0 part should just work in such setup (using such X->Wayland
"proxy").

> As for the domU side, I do not know but I presume clients shipping in
> F25 all can detect whether to use X or Wayland based on their environment.

And here may be a problem: if any client will use Wayland, those windows
will probably be unreachable to qubes-gui-agent using X.

> This is yet to be tested.
>
> >
>
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX/u11AAoJENuP0xzK19csczcH/iQTBohuEG5Oz6Hij+MVLL8H
qpWt3KAUCaXsw83FDyM/c1nEWr+8cgROfwSglrReDAOfynse/12PPUVLXNCsq++S
hLyWqI4b1vHXaRCqdWWKejPgjdWIA/fV6cJ2P6TQoYNsjK/cIIPPlvulshVOJRgP
Ze6mJC/ZUzhdIL+yfycAQFNYVnb4/KlofwbLHnjQbILW02J3DMrpW5rtceCU2bsT
vMcXTiScV8erApBg69S7PDN3lcnOjeh5CGbBT6DB2bUYiNQx1bZtwudrO0QeMqOX
CcRHJiFihZGtmQJ7ouLoDZufrrsUNBZvZ7qZwiHmrmEZEJH+TajqMP5SJ5Y9A0o=
=5Yx7
-----END PGP SIGNATURE-----