qubes-doc/user/reference/glossary.rst
Ben Grande 80c9edac96
Adapt disposable documentation up to 4.3
- Cleared misunderstandings of disposable templates, this word was
  sometimes used interchangeably with disposables;
- Deduplicate content as much as possible;
  - Reference other pages or previous sections;
  - Assume the user has read the previous sections up until the
    current section they are reading;
  - All this deduplication enables easier reading, less clutter, but
    each section doesn't stand by itself, each page does. Some things
    were reinforced on multiple sections, but limited to when
    extremely necessary to learn by reinforcement;
- Structure the files to their distinct use cases:
  - how-to-use-disposables is just the basics to learn what are
    disposables and how to use them, using GUI and CLI alternatives;
  - disposable-customization has everything advanced related to
    disposables, such as advanced usage, creation of disposables
    templates, their customization;
  - disposable-implementation assumes the user understand the previous
    pages and contains a more technical description of disposables and
    preloaded disposables as well as their implementation;
- Prepared usage for a GUIVM setup, avoiding mentions to dom0;
- Usage modes has been organized in GUI first and CLI second, grouped by
  origin such as GUIVM and app qube;
- Usage page restricts itself to "default-dvm", it's name is not
  variable like the Whonix disposable template variant and it is the
  most used disposable template, thus we avoid variables replacement
  that the user should think of the value to a definitive value to use
  when learning. Customization page could not benefit much from this
  though, as it is intended to create alternative disposable templates;
- Usage page links to Tails documentation of why using it on a VM is not
  amensiac, so it can be referenced for users that ask to have Tails in
  a VM for anti-forensics purposes;
- Updated the images to R4.3, nobody deserves to see the Qubes version
  of the Xfce application menu anymore when the new app menu rocks. The
  images also had to be updated because it was fullscreen screenshot
  on a large resolution, making it very difficult to read unless
  opening the image in a new tab and zooming in;
- Implementation page shows preloaded disposables alternatives that were
  once used or considered as a comparative for future studies, to answer
  why a different option is not being used and what requirements a
  replacement must meet;
- Content from previous releases have been deleted;
- Updates to Qrexec policy v4;
- Use rST roles;
- Change non-ASCII quotes and em-dashes to ASCII;
- Standardized text writing style, many people have contributed to these
  pages over the years, there is a lot of different writings styles
  which make the text difficult to map. I rewrote a lot of the
  paragraphs to my liking and understanding of the different stages that
  a user may go through when using disposables, and even on paragraphs
  that I didn't completely write, it was modified to follow the same
  standard with the rest of the pages. The usage must be very simple
  with just the basics, we don't want to scare the user's off of using
  disposables, we want to convince them. The customization is a bit more
  advanced, it assumes a lot more knowledge from the user to make
  decisions by themselves such as customizing applications and qube
  settings, which can affect system security. The implementation details
  do not require reading the code, it just exist to explain what is
  being used and why it was chosen.

Fixes: https://github.com/QubesOS/qubes-issues/issues/10282
For: https://github.com/QubesOS/qubes-issues/issues/1512
2025-11-13 11:44:39 +01:00

169 lines
9.5 KiB
ReStructuredText

========
Glossary
========
Primary
-------
.. glossary::
Qubes OS
A security-oriented operating system (OS). The main principle of Qubes OS is security by compartmentalization (or isolation), in which activities are compartmentalized (or isolated) in separate :term:`qube`.
- **Important:** The official name is "Qubes OS" (note the capitalization and the space between "Qubes" and "OS"). In casual conversation, this is often shortened to "Qubes". Only in technical contexts where spaces are not permitted (e.g., in usernames) may the space be omitted, as in ``@QubesOS``.
Compartment nomenclature
------------------------
.. glossary::
qube
A secure compartment in Qubes OS. Currently, qubes are implemented as Xen :term:`domain`, but Qubes OS is independent of its underlying compartmentalization technology. :term:`VM`\ s could be replaced with a different technology, and qubes would still be called "qubes". Therefore, always opt for the term ``qube`` over the other terms unless explicitly guided otherwise.
- **Important:** The term "qube" is a common noun and should follow the capitalization rules of common nouns. For example, "I have three qubes" is correct, while "I have three Qubes" is incorrect. Note that starting a sentence with the plural of "qube" (i.e., "Qubes ...") can be ambiguous, since it may not be clear whether the referent is a plurality of qubes or :term:`Qubes OS`.
- Example usage: Bank in your ``banking`` qube and web surf in your ``untrusted`` qube. That way, if your ``untrusted`` qube is compromised, your banking activities remains secure.
- Historical note: The term "qube" was originally invented as an alternative to "VM" intended to make it easier for less technical users to understand Qubes OS and learn how to use it.
domain
In Xen, a synonym for :term:`vm`. See `"domain" on the Xen Wiki <https://wiki.xenproject.org/wiki/Domain>`__. This term has no official meaning in Qubes OS.
VM
An abbreviation for "virtual machine". A software implementation of a computer that provides the functionality of a physical machine.
Qube's types
------------
.. glossary::
admin qube
A type of :term:`qube` used for administering Qubes OS.
- Currently, the only admin qube is :term:`dom0`.
app qube
Any :term:`qube` that does not have a root filesystem of its own. Every app qube is based on a :term:`template` from which it borrows the root filesystem.
- Previously known as: ``AppVM``, ``TemplateBasedVM``.
- Historical note: This term originally meant "a qube intended for running user software applications" (hence the name "app").
disposable
A :term:`disposable` is a stateless :term:`qube`, it does not save data for the next boot. These qubes can serve various uses cases that require a pristine environment. See :doc:`/user/how-to-guides/how-to-use-disposables`.
- Previously known as: ``DisposableVM``, ``DispVM``.
standalone
Any :term:`qube` that has its own root filesystem and does not share it with another qube. Distinct from both :term:`template` and :term:`app qube`.
See :doc:`/user/advanced-topics/standalones-and-hvms`.
- Previously known as: ``StandaloneVM``.
template
Any :term:`qube` that shares its root filesystem with another qube. A qube that is borrowing a template's root filesystem is known as an :term:`app qube` and is said to be "based on" the template. Templates are intended for installing and updating software applications, but not for running them.
See :doc:`/user/templates/templates`.
- No template is an :term:`app qube`.
- A template cannot be based on another template.
- Regular templates cannot function as :term:`disposable template`. (Disposable templates must be app qubes).
- Previously known as: ``TemplateVM``.
Qube's types variations
-----------------------
.. glossary::
disposable template
Any :term:`app qube` on which :term:`disposable` are based. A disposable template shares its user directories (and, indirectly, the root filesystem of the regular :term:`template` on which it is based) with all :term:`disposable` based on it.
- Not to be confused with the concept of a regular :term:`template` that is itself disposable, which does not exist in Qubes OS.
- Disposable templates must be app qubes. They cannot be regular :term:`template`.
- Every :term:`disposable` is based on a disposable template, which is in turn based on a regular :term:`template`.
- Unlike :term:`disposable`, disposable templates have the persistence properties of normal :term:`app qube`.
- Previously known as: ``DisposableVM Template``, ``DVM Template``, ``DVM``. It is advised against the use of the ``DVM`` terms as it can be interpreted by some users as an abbreviation of ``DispVM``, which a ``DVM`` is not.
named disposable
A type of :term:`disposable` given a permanent name that continues to exist even after it is shut down and can be restarted again.
- Only one instance of a named disposable can run at a time.
- Technical note: Named disposables are useful for certain :term:`service qube`\ s, where the combination of persistent device assignment and ephemeral qube state is desirable.
unnamed disposable
A type of :term:`disposable` with a temporary name that ceases to exist after the qube is shut down. Closing the first application that was opened in the disposable will trigger the qube to shut down. Thus, if there is not initial application, such is the case with Qubes Devices widget, the qube has to be manually turned off.
- Multiple instances of a unnamed disposable can run at a time.
- Technical note: Unnamed disposables are useful for certain converting, viewing and editing untrusted files, where the combination of opening multiple files in disposable qubes that you don't need to remember their name for long is desirable.
management qube
A :term:`qube` used for automated management of a Qubes OS installation via :doc:`/user/advanced-topics/salt`.
net qube
Internally known as :term:`qube` that specifies from which qube, if any, it receives network access. Despite the name, "net qube" (or :term:`app qube` to be the :term:`service qube` ``sys-firewall``, which in turn uses ``sys-net`` as its net qube.
- If a qube does not have a net qube (i.e., its ``netvm`` is set to ``None``), then that qube is offline. It is disconnected from all networking.
- The name :term:`service qube` called a "NetVM". The name of the ``netvm`` property is a holdover from that era.
service qube
Any :term:`app qube` with the primary purpose of which is to provide services to other qubes. ``sys-net`` and ``sys-firewall`` are examples of service qubes.
internal qube
A qube which has the ``internal`` feature set. Used for the :term:`management qube` and preloaded disposables. These qubes are hidden from most Qubes OS graphical applications, as they are not intended to be used directly.
GUI domain
The GUI domain handles all the display-related tasks and some system management. There can be multiple GUI domains present on the system. Every GUI domain can have its own set of privileges, permissions, managed qubes etc. By default, :term:`dom0` is the only GUI domain.
Miscellaneous
-------------
.. glossary::
dom0
:term:`domain` zero. A type of :term:`admin qube`. Also known as the **host** domain, dom0 is the initial qube started by the Xen hypervisor on boot. Dom0 runs the Xen management toolstack and has special privileges relative to other domains, such as direct access to most hardware.
- The term "dom0" is a common noun and should follow the capitalization rules of common nouns.
domU
Unprivileged :term:`domain`. Also known as **guest** domains, domUs are the counterparts to dom0. In Xen, all VMs except dom0 are domUs. By default, most domUs lack direct hardware access.
- The term "domU" is a common noun and should follow the capitalization rules of common nouns.
- Sometimes the term :term:`vm` is used as a synonym for domU. This is technically inaccurate, as :term:`dom0` is also a VM in Xen.
HVM
Hardware-assisted Virtual Machine. Any fully virtualized, or hardware-assisted, :term:`vm` utilizing the virtualization extensions of the host CPU. Although HVMs are typically slower than paravirtualized qubes due to the required emulation, HVMs allow the user to create domains based on any operating system.
See :doc:`/user/advanced-topics/standalones-and-hvms`.
firmware
Software that runs outside the control of the operating system. Some firmware executes on the same CPU cores as Qubes OS does, but all computers have many additional processors that the operating system does not run on, and these computers also run firmware.
policies
In Qubes OS, "policies" govern interactions between qubes, powered by :doc:`Qubes' qrexec system </developer/services/qrexec>`. A single policy is a rule applied to a qube or set of qubes, that governs how and when information or assets may be shared with other qubes.
An example is the rules governing how files can be copied between qubes.
Policy rules are grouped together in files under ``/etc/qubes/policy.d``
Policies are an important part of what makes Qubes OS special.
Qubes Windows Tools (QWT)
A set of programs and drivers that provide integration of Windows qubes with the rest of the Qubes OS system.
See :doc:`/user/templates/windows/qubes-windows-tools` and :doc:`/user/templates/windows/qubes-windows`.