diff --git a/services/admin-api.md b/services/admin-api.md index b761d5e6..fc98d079 100644 --- a/services/admin-api.md +++ b/services/admin-api.md @@ -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` | - | - | `\n` | @@ -188,3 +232,7 @@ a default Qubes OS installation. However, they are created anyway. `qrexec-client-vm` + +[admin-api]: ../admin-api/ +[admin-api-architecture]: /attachment/wiki/AdminAPI/admin-api-architecture.svg + diff --git a/services/mgmt-design.md b/services/mgmt-design.md deleted file mode 100644 index 5b5b9d5a..00000000 --- a/services/mgmt-design.md +++ /dev/null @@ -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