diff --git a/README.md b/README.md index 26c251d..f5deee6 100644 --- a/README.md +++ b/README.md @@ -44,11 +44,11 @@ are allowed to make. Here are some of the Global Preferences we can manage: - **clockvm**: disp-sys-net, sys-net +- **default_audiovm**: disp-sys-audio - **default_dispvm**: dvm-reader - **default_netvm**: sys-pihole, sys-firewall or disp-sys-firewall - **management_dispvm**: dvm-mgmt - **updatevm**: sys-pihole, sys-firewall or disp-sys-firewall -- **default_audiovm**: disp-sys-audio If you want to learn more about how we make decisions, take a look at our [design document](docs/DESIGN.md). @@ -64,66 +64,66 @@ You current setup needs to fulfill the following requisites: ### DomU Installation -1. Install `git` in the qube, if it is an AppVM, install it it's the - TemplateVM and restart the AppVM. +1. Install `git` in the qube, if it is an AppVM, install it it's the + TemplateVM and restart the AppVM. -2. Clone this repository: - ```sh - git clone --recurse-submodules https://github.com/ben-grande/qusal.git - ``` - If you made a fork, fork the submodule(s) before clone and use your remote - repository instead, the submodules will also be from your fork. +2. Clone the repository (if you made a fork, fork the submodule(s) before + clone and use your remote repository instead, the submodules will also be + from your fork). + ```sh + git clone --recurse-submodules https://github.com/ben-grande/qusal.git + ``` -3. Copy the [maintainer's signing key](https://github.com/ben-grande/ben-grande/raw/main/DF3834875B65758713D93E91A475969DE4E371E3.asc) - to your text editor and save the file to `/home/user/ben-code.asc`. +3. Copy the [maintainer's signing key](https://github.com/ben-grande/ben-grande/raw/main/DF3834875B65758713D93E91A475969DE4E371E3.asc) + to your text editor and save the file to `/home/user/ben-code.asc`. ### Dom0 Installation Before copying anything to Dom0, read [Qubes OS warning about consequences of this procedure](https://www.qubes-os.org/doc/how-to-copy-from-dom0/#copying-to-dom0). -1. Copy the repository `$file` from the DomU `$qube` to Dom0 (substitute - `CHANGEME` for the desired valued): - ```sh - qube="CHANGEME" # qube name where you downloaded the repository - file="CHANGEME" # path to the repository in the qube +1. Copy the repository `$file` from the DomU `$qube` to Dom0 (substitute + `CHANGEME` for the desired valued): + ```sh + qube="CHANGEME" # qube name where you downloaded the repository + file="CHANGEME" # path to the repository in the qube - qvm-run --pass-io --localcmd="UPDATES_MAX_FILES=10000 - /usr/libexec/qubes/qfile-dom0-unpacker user - ~/QubesIncoming/${qube}/qusal" \ - "${qube}" /usr/lib/qubes/qfile-agent "${file}" - ``` + qvm-run --pass-io --localcmd="UPDATES_MAX_FILES=10000 + /usr/libexec/qubes/qfile-dom0-unpacker user + ~/QubesIncoming/${qube}/qusal" \ + "${qube}" /usr/lib/qubes/qfile-agent "${file}" + ``` -2. Pass the maintainer's key from the qube to Dom0: +2. Pass the maintainer's key from the qube to Dom0: ```sh qvm-run --pass-io "${qube}" -- "cat /home/user/ben-code.asc" | tee /tmp/ben-code.asc ``` -3. Verify that the key fingerprint matches - `DF38 3487 5B65 7587 13D9 2E91 A475 969D E4E3 71E3`. You can use - Sequoia-PGP or GnuPG for the fingerprint verification: - ```sh - gpg --show-keys /tmp/ben-code.asc - # or - #sq inspect ben-code.asc - ``` +3. Verify that the key fingerprint matches + `DF38 3487 5B65 7587 13D9 2E91 A475 969D E4E3 71E3`. You can use + Sequoia-PGP or GnuPG for the fingerprint verification: + ```sh + gpg --show-keys /tmp/ben-code.asc + # or + #sq inspect ben-code.asc + ``` -4. Import the verified key to your keyring: - ```sh - gpg --import /tmp/ben-code.asc - ``` +4. Import the verified key to your keyring: + ```sh + gpg --import /tmp/ben-code.asc + ``` -5. Verify the [commit or tag signature](https://www.qubes-os.org/security/verifying-signatures/#how-to-verify-signatures-on-git-repository-tags-and-commits) - and expect a good signature, be surprised otherwise: - ```sh - git verify-commit HEAD - git submodule foreach git verify-commit HEAD - ``` +5. Verify the [commit or tag signature](https://www.qubes-os.org/security/verifying-signatures/#how-to-verify-signatures-on-git-repository-tags-and-commits) + and expect a good signature, be surprised otherwise: + ```sh + git verify-commit HEAD + git submodule foreach git verify-commit HEAD + ``` -6. Copy the project to the Salt directories: - ```sh - ~/QubesIncoming/"${qube}"/qusal/scripts/setup.sh - ``` +6. Copy the project to the Salt directories: + ```sh + ~/QubesIncoming/"${qube}"/qusal/scripts/setup.sh + ``` ## Update @@ -144,35 +144,35 @@ This method is more secure than literally copying the whole directory of the repository to dom0 but the setup is more involved. Requires some familiarity with the sys-git formula. -1. Install the [sys-git formula](salt/sys-git/README.md) and push the - repository to the git server. +1. Install the [sys-git formula](salt/sys-git/README.md) and push the + repository to the git server. -2. Install git on Dom0, allow the Qrexec protocol to work in submodules and - clone the repository to `~/src/qusal` (only has to be run once): - ```sh - mkdir -p ~/src - sudo qubesctl state.apply sys-git.install-client - git clone --recurse-submodules qrexec://@default/qusal.git ~/src/qusal - ``` +2. Install `git` on Dom0, allow the Qrexec protocol to work in submodules and + clone the repository to `~/src/qusal` (only has to be run once): + ```sh + mkdir -p ~/src + sudo qubesctl state.apply sys-git.install-client + git clone --recurse-submodules qrexec://@default/qusal.git ~/src/qusal + ``` 3. Next updates will be pulling instead of cloning: - ```sh - git -C ~/src/qusal pull --recurse-submodules - git -C ~/src/qusal submodule update --merge - ``` + ```sh + git -C ~/src/qusal pull --recurse-submodules + git -C ~/src/qusal submodule update --merge + ``` -4. Verify the commit or tag signature and expect a good signature, be - surprised otherwise (signature verification on submodules is skipped if - checking out but not merging): - ```sh - git verify-commit HEAD - git submodule foreach git verify-commit HEAD - ``` +4. Verify the commit or tag signature and expect a good signature, be + surprised otherwise (signature verification on submodules is skipped if + checking out but not merging): + ```sh + git verify-commit HEAD + git submodule foreach git verify-commit HEAD + ``` -5. Copy the project to the Salt directories: - ``` - ~/src/qusal/scripts/setup.sh - ``` +5. Copy the project to the Salt directories: + ``` + ~/src/qusal/scripts/setup.sh + ``` ### Dom0 Update by literally copying the git repository @@ -183,33 +183,33 @@ tracked by git. It would be easier to distrust the downloader qube if the project had a signed archive. The `.git/info/exclude` can exclude modified files from being tracked and signature verification won't catch it. -1. Install the helpers scripts and git on Dom0 (only has to be run once): - ```sh - sudo qubesctl state.apply dom0.install-helpers - sudo qubes-dom0-update git - ``` +1. Install the helpers scripts and git on Dom0 (only has to be run once): + ```sh + sudo qubesctl state.apply dom0.install-helpers + sudo qubes-dom0-update git + ``` -2. Copy the repository `$file` from the DomU `$qube` to Dom0 (substitute - `CHANGEME` for the desired valued): - ```sh - qube="CHANGEME" # qube name where you downloaded the repository - file="CHANGEME" # path to the repository in the qube +2. Copy the repository `$file` from the DomU `$qube` to Dom0 (substitute + `CHANGEME` for the desired valued): + ```sh + qube="CHANGEME" # qube name where you downloaded the repository + file="CHANGEME" # path to the repository in the qube - rm -rf ~/QubesIncoming/"${qube}"/qusal - UPDATES_MAX_FILES=10000 qvm-copy-to-dom0 "${qube}" "${file}" - ``` + rm -rf ~/QubesIncoming/"${qube}"/qusal + UPDATES_MAX_FILES=10000 qvm-copy-to-dom0 "${qube}" "${file}" + ``` -3. Verify the commit or tag signature and expect a good signature, be - surprised otherwise: - ```sh - git verify-commit HEAD - git submodule foreach git verify-commit HEAD - ``` +3. Verify the commit or tag signature and expect a good signature, be + surprised otherwise: + ```sh + git verify-commit HEAD + git submodule foreach git verify-commit HEAD + ``` -4. Copy the project to the Salt directories: - ```sh - ~/QubesIncoming/"${qube}"/qusal/scripts/setup.sh - ``` +4. Copy the project to the Salt directories: + ```sh + ~/QubesIncoming/"${qube}"/qusal/scripts/setup.sh + ``` ## Usage diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 54583bc..e777eee 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -18,7 +18,7 @@ Be respectful towards peers. ## Environment You will need to setup you development environment before you start -contributing. You will need Qubes OS R4 or higher. +contributing. ### Requirements diff --git a/docs/DESIGN.md b/docs/DESIGN.md index 053aea0..fff9d63 100644 --- a/docs/DESIGN.md +++ b/docs/DESIGN.md @@ -39,26 +39,21 @@ No extraneous features should be included by default besides the basic for functionality. Extra functionalities that could weaken the system can be provided via extra states that needs to be installed per the user discretion. +## Documentation + +Markdown code must follow +[Google's Markdown style guide](https://google.github.io/styleguide/docguide/style.html). +Any discrepancies with Google's style guide must be fixed or documented here +with clear motive. + +Documentation must not duplicate itself, but reference one another. +Reproducing instructions that can be found in upstream documentation is +discouraged unless the benefits of documenting it in-house, such as getting +the documentation from a single source, do outweigh the necessity of having to +modify the documentation constantly to keep up with upstream. + ## Format -### File naming - -1. Every State file `.sls` must have a Top file `.top`. This ensures that - every state can be applied with top. -2. Every project must have a `init.top`, it facilitates applying every state - by enabling a single top file. -3. State file naming must be common between the projects, it helps - understand the project as if it was any other. -4. File name must use `-` as separator, not `_`. - -### State ID - -1. State IDs must use `-` as separator, not `_`. The underline is allowed in - case the features it is changing has underline, such as `default_netvm`. -2. State IDs must always have the project ID, thus allowing to target multiple - states to the same minion from different projects without having - conflicting IDs. - ### Readme Every project should have a README.md with at least the following sections: @@ -70,6 +65,24 @@ Every project should have a README.md with at least the following sections: - Usage; and - Credits (if sourced). +### File naming + +1. Every State file `.sls` must have a Top file `.top`. This ensures that + every state can be applied with top. +2. Every project must have a `init.top`, it facilitates applying every state + by enabling a single top file. +3. State file naming must be common between the projects, it helps understand + the project as if it was any other. +4. File name must use `-` as separator, not `_`. + +### State ID + +1. State IDs must use `-` as separator, not `_`. The underline is allowed in + case the features it is changing has underline, such as `default_netvm`. +2. State IDs must always have the project ID, thus allowing to target multiple + states to the same minion from different projects without having + conflicting IDs. + ### Qube preferences #### Qube naming @@ -99,77 +112,77 @@ the same as you trust your vault. The following method tries to fix this problem, domain name is in the prefix of the qube, the label is solely related to trustworthiness of the data it is dealing with. -- **Black**: - - **Trust**: Ultimate. - - **Description**: You must trust Dom0, Templates, Vaults, Management qubes, - these qubes control your system and hold valuable information. - - **Examples**: dom0, tpl-ssh, vault, dvm-mgmt. -- **Gray**: - - **Trust**: Fully. - - **Description**: Trusted storage with extra RPC services that allow certain - operations to be made by the client and executed on the server or may - build components for other qubes. - - **Examples**: sys-cacher, sys-git, sys-pgp, sys-ssh-agent, qubes-builder. -- **Purple**: - - **Trust**: Very much. - - **Description**: Has the ability to manager remote servers via encrypted - connections and depend on authorization provided by another qube. - Examples: ansible, dev, ssh, terraform. -- **Blue**: - - **Trust**: Much. - - **Description**: TODO - - **Examples**: TODO -- **Green**: - - **Trust**: Trusted. - - **Description**: TODO - - **Examples**: TODO -- **Yellow**: - - **Trust**: Relatively trusted. - - **Description**: TODO - - **Examples**: TODO -- **Orange**: - - **Trust**: Slight. - - **Description**: Controls the network flow of data to the client, normally a - firewall. - - **Examples**: sys-firewall, sys-vpn, sys-pihole. -- **Red**: - - **Trust**: Untrusted. - - **Description**: Holds untrusted data (PCI devices, untrusted programs, - disposables for opening untrusted files or web pages). - - **Examples**: sys-net, sys-usb, dvm-browser. +- **Black**: + - **Trust**: Ultimate. + - **Description**: You must trust Dom0, Templates, Vaults, Management + qubes, these qubes control your system and hold valuable information. + - **Examples**: dom0, tpl-ssh, vault, dvm-mgmt. +- **Gray**: + - **Trust**: Fully. + - **Description**: Trusted storage with extra RPC services that allow + certain operations to be made by the client and executed on the server + or may build components for other qubes. + - **Examples**: sys-cacher, sys-git, sys-pgp, sys-ssh-agent, qubes-builder. +- **Purple**: + - **Trust**: Very much. + - **Description**: Has the ability to manager remote servers via encrypted + connections and depend on authorization provided by another qube. + Examples: ansible, dev, ssh, terraform. +- **Blue**: + - **Trust**: Much. + - **Description**: TODO + - **Examples**: TODO +- **Green**: + - **Trust**: Trusted. + - **Description**: TODO + - **Examples**: TODO +- **Yellow**: + - **Trust**: Relatively trusted. + - **Description**: TODO + - **Examples**: TODO +- **Orange**: + - **Trust**: Slight. + - **Description**: Controls the network flow of data to the client, + normally a firewall. + - **Examples**: sys-firewall, sys-vpn, sys-pihole. +- **Red**: + - **Trust**: Untrusted. + - **Description**: Holds untrusted data (PCI devices, untrusted + programs, disposables for opening untrusted files or web pages). + - **Examples**: sys-net, sys-usb, dvm-browser. ### Qube connections There are several ways a qube can connect to another, either directly with Xen or with Qrexec. If something is not required, we remove it. -- `template` is always required: - - When required, must be set to the custom-made template; - - When not possible to use, prefer StandaloneVMs instead. -- `audiovm` is rarely required on the majority of the projects: - - When required, set it to `"*default*"` to honor the global preferences. - - When not required, must be set to None; -- `netvm` is required on a lot of projects. - - When required, must not be managed to honor the global preferences. If it - requires a custom networking scheme, the state must make sure that the - netvm exists; - - When not required, must be set to None. -- `default_dispvm` is nice to have: - - When required, must guarantee that the network follows the same chain as - the calling qube in the default configuration; - - When not required, must be set to None. -- `management_dispvm` is always required: - - When required, should not be managed to honor the global preferences, - but it can make sense to set a custom management qube for debugging. - - When not required, such as on qubes that don't work through Salt, don't - touch it, it doesn't increase attack surface. +- `template` is always required: + - When required, must be set to the custom-made template; + - When not possible to use, prefer StandaloneVMs instead. +- `audiovm` is rarely required on the majority of the projects: + - When required, set it to `"*default*"` to honor the global preferences. + - When not required, must be set to None; +- `netvm` is required on a lot of projects. + - When required, must not be managed to honor the global preferences. If + it requires a custom networking scheme, the state must make sure that + the netvm exists; + - When not required, must be set to None. +- `default_dispvm` is nice to have: + - When required, must guarantee that the network follows the same chain as + the calling qube in the default configuration; + - When not required, must be set to None. +- `management_dispvm` is always required: + - When required, should not be managed to honor the global preferences, + but it can make sense to set a custom management qube for debugging. + - When not required, such as on qubes that don't work through Salt, don't + touch it, it doesn't increase attack surface. ### Qrexec call and policy -1. Don't use `*` for source and destination, use `@anyvm` instead -2. Target qube for policies must be `@default`. It allows for the real target - to be set by Dom0 via the `target=` redirection parameter, instead of - having to modify the client to target a different server via - `qrexec-client-vm`. -3. Target qube for client script must default to `@default`, but other targets - must be allowed via parameters. +1. Don't use `*` for source and destination, use `@anyvm` instead +2. Target qube for policies must be `@default`. It allows for the real target + to be set by Dom0 via the `target=` redirection parameter, instead of + having to modify the client to target a different server via + `qrexec-client-vm`. +3. Target qube for client script must default to `@default`, but other targets + must be allowed via parameters. diff --git a/salt/browser/README.md b/salt/browser/README.md index 1859436..3bf806c 100644 --- a/salt/browser/README.md +++ b/salt/browser/README.md @@ -21,7 +21,7 @@ Firefox-ESR, W3M or Lynx. ## Installation -- Top +- Top: ```sh sudo qubesctl top.enable browser sudo qubesctl --targets=tpl-browser,dvm-browser state.apply @@ -29,7 +29,7 @@ sudo qubesctl top.disable browser sudo qubesctl state.apply browser.appmenus ``` -- State +- State: ```sh sudo qubesctl state.apply browser.create diff --git a/salt/dom0/README.md b/salt/dom0/README.md index b20872f..a277f9a 100644 --- a/salt/dom0/README.md +++ b/salt/dom0/README.md @@ -15,14 +15,14 @@ etc. ## Installation -- Top +- Top: ```sh sudo qubesctl top.enable dom0 sudo qubesctl state.apply sudo qubesctl top.disable dom0 ``` -- State +- State: ```sh sudo qubesctl state.apply dom0 diff --git a/salt/dotfiles b/salt/dotfiles index 84bae87..0dd49bc 160000 --- a/salt/dotfiles +++ b/salt/dotfiles @@ -1 +1 @@ -Subproject commit 84bae87dc5da48334f81501e11cf17919ff1504b +Subproject commit 0dd49bcab48ddb7c328e1320c875780b2d9db1bc diff --git a/salt/mail/README.md b/salt/mail/README.md index b5d14b5..5439b1d 100644 --- a/salt/mail/README.md +++ b/salt/mail/README.md @@ -74,7 +74,7 @@ exploitation, as `msmtp` still needs to parse the mail to be sent. ## Installation -- Top +- Top: ```sh sudo qubesctl top.enable mail reader sudo qubesctl --targets=tpl-mail-fetcher,tpl-mail-reader,tpl-mail-sender,dvm-mail-fetcher,mail-reader,dvm-mail-sender,tpl-reader state.apply @@ -82,7 +82,7 @@ sudo qubesctl top.disable mail reader sudo qubesctl state.apply mail.appmenus,reader.appmenus ``` -- State +- State: ```sh sudo qubesctl state.apply mail.create diff --git a/salt/mirage-builder/README.md b/salt/mirage-builder/README.md index f2fbbf8..b5d528f 100644 --- a/salt/mirage-builder/README.md +++ b/salt/mirage-builder/README.md @@ -21,14 +21,14 @@ are done through the web interface, they have GitHub Web-Flow signature. This is the best verification we can get for Mirage Firewall. If you don't trust the hosting provider however, don't install this package. -- Top +- Top: ```sh sudo qubesctl top.enable mirage-builder sudo qubesctl --targets=tpl-mirage-builder,mirage-builder state.apply sudo qubesctl top.disable mirage-builder ``` -- State +- State: ```sh sudo qubesctl state.apply mirage-builder.create diff --git a/salt/sys-electrs/README.md b/salt/sys-electrs/README.md index f13016c..62bfa1c 100644 --- a/salt/sys-electrs/README.md +++ b/salt/sys-electrs/README.md @@ -26,14 +26,14 @@ At least `200GB` of disk space is required. This formula depends on [sys-bitcoin](../sys-bitcoin/README.md). -- Top +- Top: ```sh sudo qubesctl top.enable sys-electrs sudo qubesctl --targets=tpl-electrs-builder,tpl-sys-electrs,disp-electrs-builder,sys-electrs state.apply sudo qubesctl top.disable sys-electrs ``` -- State +- State: ```sh sudo qubesctl state.apply sys-electrs.create diff --git a/salt/sys-mirage-firewall/README.md b/salt/sys-mirage-firewall/README.md index 5e1dbfc..2623103 100644 --- a/salt/sys-mirage-firewall/README.md +++ b/salt/sys-mirage-firewall/README.md @@ -26,14 +26,14 @@ You can't use Mirage Firewall to be the updatevm, use another qube instead. We have built the Unikernel locally and verified that the upstream checksum and local checksum matched when comparing the same release. -- Top +- Top: ```sh sudo qubesctl top.enable sys-mirage-firewall sudo qubesctl state.apply sudo qubesctl top.disable sys-mirage-firewall ``` -- State +- State: ```sh sudo qubesctl state.apply sys-mirage-firewall.create diff --git a/salt/sys-pihole/README.md b/salt/sys-pihole/README.md index 2f7c7f5..739f118 100644 --- a/salt/sys-pihole/README.md +++ b/salt/sys-pihole/README.md @@ -68,6 +68,7 @@ Pi-hole will be installed with these default settings: - Query logging is enabled to show everything. You can change the settings via the admin interface: + - URL: http://localhost/admin - There is no password (access allowed only through localhost) diff --git a/salt/utils/tools/zsh/README.md b/salt/utils/tools/zsh/README.md index 970d1b9..2aa5380 100644 --- a/salt/utils/tools/zsh/README.md +++ b/salt/utils/tools/zsh/README.md @@ -15,14 +15,14 @@ warnings. ## Installation -- Top +- Top: ```sh sudo qubesctl top.enable utils.tools.zsh sudo qubesctl --targets=TARGET state.apply sudo qubesctl top.disable utils.tools.zsh ``` -- State +- State: ```sh sudo qubesctl --skip-dom0 --targets=TEMPLATEVMS state.apply utils.tools.zsh.change-shell