On Tuesday, June 27, 2017 at 9:58:04 PM UTC-4, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Dear Qubes Community,
>
> Joanna has just published a new post: "Introducing the Qubes Admin API".
> You can view the post on the Qubes website here:
>
> https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/
>
> The full Markdown source is reproduced below, and the image from the post
> is attached to this message.
>
> -
> 8<--
>
> - ---
> layout: post
> title: "Introducing the Qubes Admin API"
> categories:
> - articles
> - security
> author: Joanna Rutkowska
> - ---
>
> This post starts the "cool things coming in Qubes 4.0" series and focuses on
> what we call the "Qubes Admin API." This should not be confused with Qubes
> [Salt
> Stack integration], which we have already introduced in Qubes 3.2.
>
> ## High-level overview
>
> Let's start with a high-level architecture picture of how the Admin API fits
> into the Qubes OS architecture:
>
> 
>
> As we can see, the main concept behind the Admin API is to let _select_ VMs
> preform various _select_ administrative functions over the Qubes OS system.
>
> If this idea scares the hell out of you, then, my dear reader, we're on the
> same
> side. Indeed, if we're not careful, we can use the Admin API to shoot
> ourselves
> in the foot. Moreover, it might look like we're actually adding complexity
> and
> enlarging the amount of trusted code (TCB) in Qubes OS. All good intuitions.
> But
> below I argue that the opposite actually holds, i.e. that the Admin API allows
> us to actually _shrink_ the amount of trusted code, _simplify_ trust
> relationships in the system, and ultimately to improve the overall security at
> the end of the day. It's a bit like comparing SSH to Telnet. Admittedly, at
> first sight, the SSH protocol has much more complexity than Telnet, yet no one
> questions today that SSH is actually significantly more secure than the much
> simpler Telnet.
>
> So, let's first quickly look at examples of why we have introduced the Admin
> API, i.e. what problems it helps to solve and how.
>
> ## Management VMs
>
> For Qubes OS to become suitable for use in large organizations and/or
> corporate
> environments, it inevitably must become remotely manageable by entities such
> as
> corporate IT departments. There are, of course, many ways to implement this,
> but
> most would punch too many holes in the Qubes security model. For example, if
> we
> wanted to run some management agent in dom0, this would not only open up
> possible ways of attacking the whole system by exploiting potential bugs in
> the
> agent itself, but it would also require us to allow networking in dom0,
> exposing
> it to a number of additional attacks.
>
> The Admin API solves this problem elegantly without requiring network access
> to
> dom0, and we show exactly how below.
>
> Additionally, the Admin API nicely complements our existing [Salt Stack
> integration]. While the latter is perfect for pre-configuration at install
> time,
> the former is ideal for ongoing system maintenance, monitoring, and on-demand
> provisioning of VMs.
>
> Last but not least, we've designed the Admin API with the goal of allowing
> very
> strict "need to know" (and "need to do" for that matter) rules. This means
> that
> it should be possible to have admin roles (implemented as specific VMs) that
> would be able to e.g. provision and manage a user's AppVMs, **but not be able
> to
> read the user's data!** Of course, this is more tricky than it might seem when
> we look at the diagram above, and I discuss some of the catches and solutions
> below. We hope this will pave the way for organizations to embrace the idea of
> **non-privileged admins**.
>
> ## The GUI domain
>
> In the current Qubes architecture we've combined two different subsystems: 1)
> the (trusted) GUI subsystem and 2) the Admin stack. They're both in the same
> VM:
> the almighty dom0.
>
> This has somewhat made sense, since the GUI subsystem, which comprises the
> Window Manager, X server and graphics drivers, must be trusted anyway. After
> all, the GUI subsystem "sees" all your sensitive data, and it can also mimic
> any
> user actions by injecting keystrokes and/or mouse movements.
>
> Also, in contrast to traditional desktop systems, the Qubes GUI subsystem is
> very well isolated from the external world (user apps, USB devices,
> networking,
> etc.), which means there is very little chance of compromising it from the
> outside.
>
> Yet, there are several good reasons to move the GUI code away from the Admin
> VM
> (i.e. dom0) to a separate, _less_ trusted and _less_ privileged VM:
>
> 1. The possibility of efficiently separating the user and admin roles. This is
>somewhat complementary to the admin de-privile
