Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-10-01 01:25:40 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge mgmt-design into admin-api

Browse Source
This commit is contained in:
Andrew David Wong 2017-06-26 22:02:29 -05:00
parent aa5149c19d
commit c591cabd82
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
2 changed files with 51 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
services/admin-api.md
View File

@ -5,17 +5,61 @@ permalink: /doc/admin-api/
redirect_from:
- /doc/mgmt/
- /doc/mgmt1/
- /doc/mgmt-architecture/
- /doc/admin-api-architecture/
---
# Admin API
# Qubes OS Admin API
*(This page is the current draft of the proposal. It is not implemented yet.)*
The API should be implemented as a set of qrexec calls. This is to make it easy
to set the policy using current mechanism.
## Goals
The goals of the Admin API system is to provide a way for the user to manage
the domains without direct access to dom0.
Foreseen benefits include:
- Ability to remotely manage the Qubes OS.
- Possibility to create multi-user system, where different users are able to use
different sets of domains, possibly overlapping. This would also require to
have separate GUI domain.
The API would be used by:
- Qubes OS Manager (or any tools that would replace it)
- CLI tools, when run from another VM (and possibly also from dom0)
- remote management tools
- any custom tools
## Threat model
TBD
## Components
![Admin API Architecture][admin-api-architecture]
A central entity in the Qubes Admin API system is a `qubesd` daemon, which
holds information about all domains in the system and mediates all actions (like
starting and stopping a qube) with `libvirtd`. The `qubesd` daemon also manages
the `qubes.xml` file, which stores all persistent state information and
dispatches events to extensions. Last but not least, `qubesd` is responsible for
querying the RPC policy for qrexec daemon.
The `qubesd` daemon may be accessed from other domains through a set of qrexec
API calls called the "Admin API". This API is the intended
management interface supported by the Qubes OS. The API is stable. When called,
the RPC handler performs basic validation and forwards the request to the
`qubesd` via UNIX domain socket. The socket API is private and unstable. It is
documented [FIXME currently it isn't -- woju 20161221] in the developer's
documentation of the source code.
## The calls
The API should be implemented as a set of qrexec calls. This is to make it easy
to set the policy using current mechanism.
| call | dest | argument | inside | return | note |
| ------------------------------------- | --------- | --------- | ----------------------------------------- | --------------------------------------------------------- | ---- |
| `admin.vmclass.List` | `dom0` | - | - | `<class>\n` |
@ -188,3 +232,7 @@ a&nbsp;default Qubes OS installation. However, they are created anyway.
`qrexec-client-vm`
<!-- vim: set ts=4 sts=4 sw=4 et : -->
[admin-api]: ../admin-api/
[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg

57
services/mgmt-design.md
View File

@ -1,57 +0,0 @@
---
layout: doc-full
title: Admin API architecture
permalink: /doc/admin-api-architecture/
redirect_from:
- /doc/mgmt-architecture/
---
# Qubes OS Admin API Architecture
*(This page is the current draft of the proposal. It is not implemented yet.)*
## Goals
The goals of the Admin API system is to provide a way for the user to manage
the domains without direct access to dom0.
Foreseen benefits include:
- Ability to remotely manage the Qubes OS.
- Possibility to create multi-user system, where different users are able to use
different sets of domains, possibly overlapping. This would also require to
have separate GUI domain.
The API would be used by:
- Qubes OS Manager (or any tools that would replace it)
- CLI tools, when run from another VM (and possibly also from dom0)
- remote management tools
- any custom tools
## Threat model
TBD
## Components
![Admin API Architecture][admin-api-architecture]
A central entity in the Qubes Admin API system is a `qubesd` daemon, which
holds information about all domains in the system and mediates all actions (like
starting and stopping a qube) with `libvirtd`. The `qubesd` daemon also manages
the `qubes.xml` file, which stores all persistent state information and
dispatches events to extensions. Last but not least, `qubesd` is responsible for
querying the RPC policy for qrexec daemon.
The `qubesd` daemon may be accessed from other domains through a set of qrexec
API calls called the [Admin API][admin-api]. This API is the intended
management interface supported by the Qubes OS. The API is stable. When called,
the RPC handler performs basic validation and forwards the request to the
`qubesd` via UNIX domain socket. The socket API is private and unstable. It is
documented [FIXME currently it isn't -- woju 20161221] in the developer's
documentation of the source code.
[admin-api]: ../admin-api/
[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg