[clug] QubesOS event channels clarification [Was: Re: Canberra Linux Users Group Meeting - 23 July 2015]

Paul Harvey csirac2 at gmail.com
Fri Jul 24 14:32:10 UTC 2015

Thanks everybody for coming to the talk and asking great questions!

There was some discussion around "Why Xen, and not KVM or something
else". I mentioned the affinity the QubesOS project has with Xen
historically, but also clumsily tried to explain the "secure" event
channel inter-VM communication mechanism that Xen has (which Qubes
uses for its qrexec and file-copy etc. services).

A related line of discussion was: why would I trust the QubesOS
services more than, say, samba or NFS.

Central to both threads of thought that I failed to communicate were
the inherent design of Xen event channels: they're simple, they're
shared ring buffers (so out-of-bounds access result in a hardware
(MMU) protection fault), and this technology underpins the vast
majority of cloud providers currently in business today.

The Linux foundation has a great presentation [1] from 2013, the first
few slides especially from page 4 really explain what I failed to
communicate on Thursday night. The rest of the presentation is also
interesting, discussing the development of (the now completed)
enhancements being made to Xen to improve scalability of event
channels and the (at the time) new FIFO ABI for inter-domain

In David Chisnall's "The definitive guide to the Xen hypervisor",
there's a chapter "Understanding How Xen Approaches Device Drivers"
where I found a great excerpt [2] on how the event channels are
implemented: shared ring buffers between VMs, created/maintained in
page grant tables by the hypervisor.

There's a bit more about FLASK and the Xen Security Modules (a kind of
SELinux applied to Xen hypervisor, dom0 and domU guests, their
resources, hypervisor privileges and capabilities) on the xen website
[3]. I would imagine that most cloud computing providers using xen
(Amazon, Rackspace, DigitalOcean, etc.) as well as expensive corporate
stuff Eg. Citrix solutions are using XSM to secure their "clouds".

But Qubes doesn't make use of XSM. One of their security advisories
includes some commentary [4] - which matches their attitudes on the
mailing lists - that the project seems to rather avoid adding
complexity when it comes to solving security problems, to the extent
that it often feels like they're weakening some aspects we take for
granted in normal Linux distros... I didn't mention that AppVMs are
usually shipped with passwordless sudo by default ("because local
privesc bugs are a dime a dozen in Linux"), and things like
SELinux/AppArmor are over-complicated distractions that just add more
failure modes and suck the energy out of other more important areas.
In a way I can't blame them: many of these mechanisms are
over-complicated and have surprising, non-obvious and subtle failure

In summary I think Qubes is a great concept with a lot of promise -
it's still geeky but I suspect way less geeky than telling people to
run multiple VMs in VirtualBox, while giving you better protection
anyway. There's a lot to be said for the importance of usability when
it comes to effective security!

Assuming there's interest, hopefully before next year rolls around
I'll be in a position to offer an equivalent talk on my next interest,
MirageOS [5] or one of its friends - this is an example of the
"unikernel" approach to securing services: frameworks which allow you
to build applications baked into a dedicated OS that runs directly
under and with the Xen hypervisor, using its capabilities and features
to get work done and access resources.

The idea being, that with only the bare minimum code required to run a
service, there should be fewer vulnerabilities - you can't hack what
isn't there!

[1] https://events.linuxfoundation.org/images/stories/slides/lfcs2013_liu.pdf
[2] http://www.informit.com/articles/article.aspx?p=1160234&seqNum=3
[3] http://wiki.xen.org/wiki/Xen_Security_Modules_:_XSM-FLASK
[4] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-007-2013.txt
[5] https://mirage.io/

On 13 July 2015 at 22:59, Steve Walsh <steve at nerdvana.org.au> wrote:
> (Sending on behalf of Steve Hanley, as he's otherwise indisposed)
> Canberra Linux Users Group Meeting - 23 July 2015
>  =================================================
>  Date:          23 July 2015 (Fourth Thursday of the month)
>  =================================================
>  Time:          18:15 - 18:55
>  Abstract:      It's BeerSIG time!
>                 'What's BeerSIG?' I hear you ask! BeerSIG is a social
> gathering, and an
>                 opportunity to get together with like minded people and
> share a social pint
>                 or two before the meeting.
>  Location:      Wig and Pen, Llewellyn Hall, Canberra School of Music
>  =================================================
>  Time:          19:00 - 21:00 (or when it finishes)
>  Speaker:       Paul Harvey
>  Abstract:      I've been using QubesOS https://www.qubes-os.org/ for over 6
> months,
>                 and although it's complicated my life a little, I now feel
> naked without it!
>                 I'd like to talk about why Qubes is more than just a bunch
> of VMs:
>                  - Helps mitigate against hostile USB devices (I'll bring a
> USB rubber
>                     ducky configured for hostility, just to demonstrate)
>                  - Helps contain malicious PDFs and (eventually) other
> documents
>                  - Helps mitigate flaws inherent in the now decades-old
> design/architecture
>                     of X11, while at the same time giving a unique, somewhat
> seamless
>                     GUI experience for running different apps in different
> VMs
>                  - Helps contain exploits that might occur in kernel network
> drivers
>                  - Helps reduce the scope of malware impact by containing
> its influence to
>                     just a few filesystem locations that actually persist
> across AppVM reboots:
>                     Eg. /home and /usr/local directories (the rest of the
> root filesystem usually
>                           comes from a template rootfs that's instantiated
> on every AppVM start)
>                  - Provides a neat point & click way to chain different
> networking VMs together
>                     in front of any of your AppVMs (firewall, IDS, proxy,
> Tor, etc)
>                  - Improves memory utilization by using fancy xen stuff to
> share/release free
>                     memory among running AppVMs
>                 ... among other things
>  Venue:         Room N101
>                 Computer Science and Information Technology Building
>                 North Road
>                 The Australian National University
>                 See http://clug.org.au/ for more directions and a map
>  Food/drink:    Pizza and soft drink/juice. Come hungry, and bring
>                 about $6 to cover the cost of your share if you
>                 want some.
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux

More information about the linux mailing list