On Sun, Sep 11, 2016 at 1:13 AM Vít Šesták < [email protected]> 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 > [email protected]. > To post to this group, send email to [email protected]. > 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. > -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CACr%3DtZdvvEN%3DEjPdEQPS0Ru1QNcO5J7Dddh3LcS3c8ndRbUXnQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
