Re: Qubes Admin API

[Joanna Rutkowska]

On 05/10/14 14:51, Joanna Rutkowska wrote:
> On 05/10/14 12:03, Hakisho Nukama wrote:
>> On Tue, Jan 7, 2014 at 6:19 PM, Joanna Rutkowska
>> <joa...@invisiblethingslab.com> wrote:
>>> There is a very high probability we will introduce remote management
>>> support for Qubes OS sometime this year. This will be most likely
>>> implemented via a dedicated management VM(s) which will be
>>> "semi-trusted" and allowed to ask Dom0 for certain actions (e.g. create
>>> a new VM for me with this image, complete remote attestation, etc) via a
>>> specially designed protocol (qrexec-based, of course).
>>>
>>> This management infrastructure should not only be secure, meaning to
>>> prevent non-authorized admins to compromise somebody's Qubes OS, but
>>> also should allow for "Anti-Snowden Protection" (ASP?), meaning the
>>> authorized admins, who were explicitly allowed to manage somebody's
>>> Qubes OS laptop, should still not be able to steal the user data. Cool, huh?
>>>
>>> This will be a proprietary solution for our customers (in terms of
>>> supporting integration with XYZ management system), but the core
>>> infrastructure for this should be open-source, and should make it also
>>> possible for "enthusiasts" to also manage Qubes remotely and securely
>>> "by hand" (and write custom agents as well).
>>>
>>> There are lots of exciting things coming to Qubes R3...
>>>
>>> joanna.
>>>
>>
>> Are all provisioning tools for this (and other) tasks supported?
>> Like salt, ansible, chef, puppet and the others [1].
>> And how will the MgmtVMs be implemented?
>> As a pipe for these orchestration software with some auditing in between?
>>
>> 1. Inspect this {playbook, runmodule, script}
>> 2. Modify this {playbook, script, ...} (and send diff for approval to Mgmt)
>> 3. Run this {playbook, script, ...}
>>
>>
>
> We're rather thinking about something more generic. Some background
> first -- if we think about a Qubes OS system, there are 3 logically
> separate things to manage:
>
> 1) All the VMs (but excluding the Dom0/AdminVM)
>
> 2) The Qubes system configuration (essentially qubes.xml), including all
> the policies (qrexec, firewalling, and more in the future)
>
> 3) The Dom0 (aka AdminVM in Qubes Odyssey nomenclature), e.g. installing
> Dom0 software updates.
>
> Now, if you look at the current Qubes OS we do have two types of tools
> for managing Qubes configuration as well as all the VMs, these are:
> 1) Qubes command line tools in Dom0, the qvm-* and qubes-* tools,
> 2) The Qubes Manager GUI application.
>
> They represent two different frontends to the Qubes management stack.
> They work by assuming direct access to the /var/lib/qubes/qubes.xml
> file, which is a central database about the Qubes system configuration,
> and direct access to Xen management interfaces, which is the source for
> getting information about the system state (in Qubes R3 this replaced by
> libvirt of course).
>
> What we would like to do in Qubes R3 next is to create a service
> (daemon), lets call it qubesd (yeah, like xend), that would be exposing
> the above functionality over a well defined interface, and be the only
> one entity responsible for managing qubes.xml, talking to libvirt, etc.
> Let's call this interface Qubes Admin API.
>
> Now, why not expose (some subsets of) this Qubes Admin API to some
> (select) VMs, not just internally inside the AdminVM?
>
> The immediate use of this is to allow for a separate GuiVM, distinct
> from AdminVM. One benefit it brings that we can now use essentially any
> OS as the GUI domain. Want Ubunut HVM as your GuiVM? No problemo -- just
> need to build qvm-tools and Qubes Manager for Ubuntu. Want Windows as
> your GUI domain? Again, no problem, just make sure to install Xen PV
> drivers and build qvm-tools and Qubes Manager (both of the latter are
> written in python). Note that Qubes "Start Menu" is just a collection of
> shortcuts that use "qvm-run ..." commands, so no special code to support.
>
> We can easily go further than that! You don't want the GuiVM to be able
> to modify Qubes Policy, only to be able to start/stop VMs and interact
> with programs there (something the corporate customers would love)? We
> can do that too.
>
> Want to have two GuiVMs to support two different users (making Qubes a
> multi-user system)? Possible.
>
> We can easily see that a management VM, understood as a place where your
> remote management agent is running, can also be considered as another
> form of a GuiVM (e.g. it gets qvm-tools or it calls AdminAPI directly).
>
> The challenges to make this correctly are: 1) how to design this
> AdminAPI to be easily serialize'able over a socket-like channel such as
> qrexec? And 2) how to implement flexible policing for this?
>
> Example of policy rules I might want to use:
>
> * Give VM a right to create VM(s) and the right to manage _only_ those
> VMs it created, but excluding ability to change/set policy for those VMs
> (e.g. not able to allow qubes.VMShell for those VMs it created)
>
> * A read-only access to the system configuration and logs (e.g. auditing)
>
> * Full management rights but excluding the rights to change/remove logs
>
> One approach to implement the above policing is to manually divide
> AdminAPI into several sub-APIs and expose each as a different qrexec
> service (qubes.AdminAPI.ReadAccess, qubes.AdminAPI.OwnVMsOnly,
> qubes.AdminAPI.Full, etc). In that case we would be easily able to grant
> admin rights using the existing qrexec policy engine. Not sure if this
> is the best (most elegant and flexible) approach though.
>
> Also, one remaining thing regarding remote management is managing
> Dom0/AdminVM with regards to things that are beyond the scope of the
> Qubes management stack. An example here would be to install a new driver
> to support a SATA device. I almost wrote: "... to support a new graphics
> card", but that would not be needed, as in the model outlined above,
> with GUI domain living in another VM, this would not be necessary.
> Generally this model would mean that Admin VM is really slim and runs
> essentially no user-visible software, so there should be few reasons to
> tinker with it. And we could always expose a VM-triggable qrexec service
> to install updates (from trusted sources only) in the Admin VM without
> compromising security.
>
> joanna.
>

Forwarding to qubes-devel. Please respond there.

j.

[Hans Walter]

Good Evening,

On 05/10/14 08:55, Joanna Rutkowska wrote:

>> What we would like to do in Qubes R3 next is to create a service
>> (daemon), lets call it qubesd (yeah, like xend), that would be exposing
>> the above functionality over a well defined interface, and be the only
>> one entity responsible for managing qubes.xml, talking to libvirt, etc.
>> Let's call this interface Qubes Admin API.

Sounds awesome! But for now how is the future of the current qubes
python package? What is the ETA on the new API? 3 months or 3 years?

The background is, that I'm (litereally) right now patching in LVM
support. I added a flag to qvm-create and implementing an own QubesVM. I
hoped that it would be good enought that you can merge it. Does it make
sense to still work on the python package, if you want to introduce a
new API?

I also did some (what i see as) "cleanup" in qvm-create (patches
attached). Does this make sense? Are you guys interested in some clean
up in the core/core-modules package also? Just using the python provided
standard logger, would save the debug parameter in quite few places.

Hans

[Marek Marczykowski-Górecki]

On 10.05.2014 15:47, Hans Walter wrote:
> Good Evening,
>
> On 05/10/14 08:55, Joanna Rutkowska wrote:
>
>>> What we would like to do in Qubes R3 next is to create a service
>>> (daemon), lets call it qubesd (yeah, like xend), that would be exposing
>>> the above functionality over a well defined interface, and be the only
>>> one entity responsible for managing qubes.xml, talking to libvirt, etc.
>>> Let's call this interface Qubes Admin API.
>
> Sounds awesome! But for now how is the future of the current qubes
> python package? What is the ETA on the new API? 3 months or 3 years?

Hard to say, but rather months than years.

> The background is, that I'm (litereally) right now patching in LVM
> support. I added a flag to qvm-create and implementing an own QubesVM. I
> hoped that it would be good enought that you can merge it. Does it make
> sense to still work on the python package, if you want to introduce a
> new API?

In Odyssey (aka R3) there are some major changes in backend code. Especially
storage handling code is moved into separate classes. While the code itself is
quite similar, applying your storage patches will need to be done manually.
Functions layout is very similar as in current QubesVm, just moved into
separate class.
Fortunately separating storage handling have some nice effect here - you will
be able to simply implement new storage backend (separate storage class)
instead of forking QubesVm class.

> I also did some (what i see as) "cleanup" in qvm-create (patches
> attached). Does this make sense? Are you guys interested in some clean
> up in the core/core-modules package also? Just using the python provided
> standard logger, would save the debug parameter in quite few places.

Generally qvm-* tools have very little changes in R3, so such cleanups (I
haven't looked at them yet...) may have a sense for both R2 and R3. Standard
logging also looks very promising. But we don't want introduce any big change
(new features) before final R2 release.

--
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?

[Hans Walter]

Hi,

So whats the eta for the new backend? I really want to integrate my
hacked shell-scripts with Qubes to use LVM.

>> I also did some (what i see as) "cleanup" in qvm-create (patches
>> attached). Does this make sense? Are you guys interested in
>> some clean up in the core/core-modules package also? Just using
>> the python provided standard logger, would save the debug
>> parameter in quite few places.
>
> Generally qvm-* tools have very little changes in R3, so such
> cleanups (I haven't looked at them yet...) may have a sense for
> both R2 and R3. Standard logging also looks very promising. But we
> don't want introduce any big change (new features) before final R2
> release.

I'm still interested in helping you guys with small cleanups to make
the qvm-tolls nicer to use.

Hans

[Joanna Rutkowska]

We plan to release rc2 sometime tomorrow-ish, and r2 sometime at the
beginning of September, with r3 beta code following soon afterwards. So,
September-ish.

>
>>> I also did some (what i see as) "cleanup" in qvm-create (patches
>>> attached). Does this make sense? Are you guys interested in
>>> some clean up in the core/core-modules package also? Just using
>>> the python provided standard logger, would save the debug
>>> parameter in quite few places.
>>
>> Generally qvm-* tools have very little changes in R3, so such
>> cleanups (I haven't looked at them yet...) may have a sense for
>> both R2 and R3. Standard logging also looks very promising. But we
>> don't want introduce any big change (new features) before final R2
>> release.
>
> I'm still interested in helping you guys with small cleanups to make
> the qvm-tolls nicer to use.
>
> Hans
>
>

In the meantime you can have a look at tickets for "2.1" milestone,
which are believed to be r2/r3 independent so should be easily mergable
to both r2 and r3:

https://wiki.qubes-os.org/report/3


joanna.

[Hans Walter]

On 08/04/14 11:18, Joanna Rutkowska wrote:

> In the meantime you can have a look at tickets for "2.1" milestone,
> which are believed to be r2/r3 independent so should be easily mergable
> to both r2 and r3:

The issue #441did catch my attention. You basically need a method for
defining messages and matching some rules on them. The folks from Plan9
had a similar issue and created a tool called plumber. It basically is a
method for defining rules for inter domain communication
http://man.cat-v.org/9front/6/plumb This could go even so far that you
can replace the Qubes RPC through plumbing rules.

I'm not sure if it's possible to port the source code of plumber from
plan9. But a similar solution could be applied. I think i could come up
with some code for parsing plumbing rules.

Would this help or is it an overkill solution?

Hans

[Joanna Rutkowska]

The ticket #441 is *not* about coming up with inter-VM communication
channels. For inter-domain communication we already have qrexec for that.

Anyway, let's discuss qrexec vs plumber below.

The qrexec provides (policy controlled) stdin/stdout pipes between
processes running in different domains (VMs) without looking into what's
going on in those pipes.

From what I see plumber might be considered a bit more high-level than
our qrexec, as it provides also structure serialization. In qrexec we
don't provide any such serialization generator/parser, because we don't
like the complexity of such code, and its potential to have exploitable
bugs.

Our qrexec has been optimized for simplicity. We believe this translates
to a decent security, i.e. difficulty to exploit the qrexec receiver
from the originating domain, and vice versa.

Writing services for qrexec is like writing any programs that
communicate with each other via stdin/stdout (and the qrexec policy only
controls establishing of these connections). If one wants some more
complex IDL-like functionality, one should be able to use 3rd party
libraries for that on top of the existing qrexec channel. By not having
such (complex, and often not needed for our services) code built into
qrexec (and run by default on each connection), we offer users/admins
the flexibility (via qrexec policy) to choose which domains should be
running such more complex services, or which might be allowed to use
those services, allowing for fine-grained risk-management.

If I misunderstood what plubmer is for, please correct me and explain.

joanna.

[Hans Walter]

On 08/05/14 11:05, Joanna Rutkowska wrote:

> If I misunderstood what plubmer is for, please correct me and
> explain.

No I think you get it right. I admit it's not a proper solution for
Qubes. But reading the examples you provide in the issue #441 i just
notice a resemblance to some features of rule matching in plumber. So
spinning further: Plumber routes messages, but qrexec-daemon could
route RPC calls.

At the moment the AppVM has to tell qrexec what it wants to do
specifically: `qrexec-client-vm target_vm_name RPC_ACTION_NAME
rpc_client_path client arguments`

Reading your examples I thought the best way to implement it, would be
the routing of the RPC calls in some rules in the dom0.

So the AppVM executes `qrexec-client-vm RPC_ACTION_NAME arguments` and
the logic in the qrexec-daemon would match the TargetVM and open the
specific program in the targetvm from some simple rules.

It could be made completely backward compatible with old style
invocation of qrexec-client.


Example for some rules:

> Or the user might define that all .PDF files are to be opened in
some other VM. Or run through the PDF converter.

RPC_ACTION_NAME: OpenPDF
src_vm:*
dst_vm: PdfVM
dst_exec: /bin/pdfconverter $arguments

> Or that all the files from ~/Downloads should be opened in
DispVM/other VM.

RPC_ACTION_NAME: OpenAny
src_vm:*
dst_vm: DispVM
dst_exec: /bin/open-any $arguments

(open-any could be some programm matching mime-type to some default
kde program)

You could even create a rule for old style invocation:

RPC_ACTION_NAME: *
src: OldStyleVM
dst_vm: $targetVM
dst_exec: $rpc_client_path $client $arguments

or even:

RPC_ACTION_NAME: *
src: OldStyleVM
dst_vm: (dispVM || SomeOtherVM)
dst_exec: $rpc_client_path $client $arguments


Btw this could make policies obsolete. At the moment you use them
because any VM can do any RPC call on any other VM.


Hans