Browse Source

docs: update them a bit, add a clear cut warning

master
parent
commit
58e4637b28
Signed by: govanify GPG Key ID: DE62E1E2A6145556
9 changed files with 77 additions and 43 deletions
  1. +1
    -1
      README.md
  2. +48
    -0
      docs/README.txt
  3. +0
    -7
      docs/bootloader.txt
  4. +16
    -1
      docs/code-architecture.txt
  5. +8
    -17
      docs/design.txt
  6. +4
    -4
      docs/user-manual.txt
  7. +0
    -13
      docs/virtualization.txt
  8. BIN
      secrets/assets/emet-selch.md
  9. BIN
      secrets/infrastructure/emet-selch/amaurot.nix

+ 1
- 1
README.md View File

@ -10,7 +10,7 @@ Currently the machines populated by this configuration are:
WARNING: This is a very heavily WIP project and has an uncommon threat model, as
such you might want to really document yourself before using parts of this
software!
software! Please read `docs/README.txt` at the very least!
Do not forget to run `pre-commit install` to get the formatting hooks running


+ 48
- 0
docs/README.txt View File

@ -0,0 +1,48 @@
navi's documentation
--
Before we begin, I'd like to state that navi is INCOMPLETE and has a bunch of
half-assed/unfinished features.
While I think the general code architecture and design of the project are fairly
commendable, them being unfinished makes them anti-features, driving users into
a sense of security. Please, before sharing parts of my configuration, do keep
that in mind and run your own audits, I haven't audited myself the configuration
yet!
navi also, in a perfect world, has a few features that are currently disabled:
always-on Tor proxying, Tor based infrastructure DNS lookup, malloc hardening,
"hidden" backups, heck even sandboxing which is currently a joke.
All of those features have, as of now, important enough quirks that I don't
feel confident leaving them enabled by default but they are still planned,
I just need to take some time to polish everything up!
As a last note, currently mobile devices are not planned to be supported in
navi. This is because of the Verified boot with remote signing approach that is
taken to enforce security on devices by any recent Android phones.
While I have my own qualms with this approach[1], I think this is an ill fit for
navi, where lateral movement between device groups (servers->headfull) is
designed to be impossible.
With that said I can still recommend GrapheneOS for that usage, with Tor as an
always-on VPN, disabling all connections before startup and possibly an
https://attestation.app setup in one of navi's server. If, as assumed in navi,
your attacker is a state-level threat, you might want to either leave the device
in WiFi only by enabling airplane mode or get a SIM card that is unrelated to
your current identity.
Thanks for reading all of those warnings! I'd just like to state that most of
this documentation was written at the start of navi and was barely updated after
and might not reflect the current state of things, code is authoritative, doc
isn't! Feel free to jump to code_architecture.txt for more information about
this codebase and don't get too mad at me :-)
--
[1]: The software provider can be backdoored and be forced to send out their
keys, unwillingly. While solutions like grapheneos tries to mitigate this by
only having minimal infos on your device (model, version, ip) updates can still
be targetted nevertheless by geoip-based targetting and/or VPN recognition, if
the user is using one. As a side-note this is a _hard_ problem and I have no
solutions to it, only mitigations. navi is only vulnerable to it at multiple
levels: git cloning heuristics, nixos cache backdooring, etc.

+ 0
- 7
docs/bootloader.txt View File

@ -4,13 +4,6 @@ The bootloader is GRUB based, with stage 1 requiring a password to boot into
stage 2 without any recovery options. navi's grub definition will be used for
any multiboot definition.
we should (not doneyet):
* enforce check_signatures on kern
* rename menu entries
* disable menu timeout entirely, only enable on trigger
Some thoughts on tamper proofing:
A tamper evident boot cannot, at the time being, properly be implemented.


+ 16
- 1
docs/code-architecture.txt View File

@ -1,5 +1,5 @@
navi's code architecture is divided into 4 parts: components, profiles,
infrastructure and assets.
infrastructure and assets, with a possible additional secrets top-level.
A profile is composed of multiple components, and a device will usually add
device-specific information to components that requires it, while the assets
@ -23,3 +23,18 @@ components directly (eg to add websites your device hosts).
Profiles are thus done out of convenience to avoid boilerplate code across
different machines.
Infrastructure, finally, organizes configuration that should be shared between
your devices but is not a profile (eg your default username) along with every
device's specific configuration.
Secrets, additionally, can create an additional top-level tree of all of the
above, which should not be public.
If lateral information is an issue for you, you might want to use submodules for
each device built into your main configuration and make git non fail when
failing to fetch a submodule, preventing any information leakage. This is not a
strong issue in my current configuration as no sensitive informations are shared
between devices that others do not necessarily know about. All sensitive data,
as a rule of thumb, lives outside of Nix.

+ 8
- 17
docs/design.txt View File

@ -66,21 +66,19 @@ programs:
root:
* dhcpcd
* sshd
* NetworkManager & friends
* systemd and friends
custom user:
* tor
* nscd
* dbus-daemon
* polkit \ might be able to remove those two
* rtkit /
* polkit < might be able to remove in the future
standard user:
* ibus
* Xwayland
* alacritty
* sway
* firefox
* mail(isync+msmtp+neomutt+notmuch+abook+lynx)
* mail(isync+msmtp+neomutt+notmuch+lynx)
* music(cmus)
* dev(vim/ssh etc)
* weechat
@ -221,13 +219,12 @@ Per-application security for the root user is basically:
* dhcpcd is so small and limited in its scope that I doubt it would be
likely to break into the system through them.
* At this point attacking NetworkManager would result in attacking its API,
which I would hope is secure enough.
* wpa_supplicant, which is closed off to external communications. A successful
takeover would leave me almost as surprised as sshd.
So the shortest chain so far seems to be firefox->sway->systemd or
firefox->sway->NetworkManager since no I
cannot think of a successful sandbox escape from isync and without sandbox
escape no DBus access is earned.
since I cannot think of a successful sandbox escape from isync
and without sandbox escape no DBus access is earned.
Finally per-application security for constrained user:
@ -243,18 +240,12 @@ Finally per-application security for constrained user:
couple of bugs. As it is in a restrained environment though I doubt it would
be of much use when developping a chain.
* rtkit is very unlikely to be used as an attack factor because of how small its
scope is but it's using dbus so nothing is certain.
* nscd is basically the same as rtkit, but without dbus. Attack is fairly
unlikely at this stage.
Kernel security is hardened through the NixOS hardened profile, but that only
helps so much compared to removing entire classes of bugs altogether.
So, for a full remote root compromise, the shortest attack vectors seem to be
firefox->sway->{systemd,NetworkManager,kernel} (or kernel directly if you're the
firefox->sway->{systemd,kernel} (or kernel directly if you're the
luckiest bastard in the world). A full remote user compromise would then be
firefox->sway as RCE is useless without a double sandbox escape in this
scenario, a local powered on compromise would simply require plugging the correct device
@ -284,6 +275,6 @@ is undeniable.
Overall it's very much a proof-of-concept and a fun thought exercise but I think
this ain't half bad.
[1]: TODO make grub tamper proof
[1]: see bootloader.txt
NB: This is in an ideal world, some of those features are not yet in navi!

+ 4
- 4
docs/user-manual.txt View File

@ -1,7 +1,9 @@
navi tools are not necessarily the most user friendly if you don't know what
they do, but are fairly optimized towards productivity.
This document intends to give a digestible list of the most useful features that
navi has to offer.
This document intends to give a digestible list of the most discernible
useful features that navi has to offer. Feel free to checkout the original
projects manuals, as this document only aims to document configurations specific
to navi!
The text editor: Neovim
@ -125,5 +127,3 @@ The shell (fish) -> TODO
can simply run "nbuild <package>" where <package> is your package name, eg
"nbuild pcsx2" and it will drop you into a shell environment that has all the
required setup to build your software!
The Terminal Multiplexer (tmux) -> TODO

+ 0
- 13
docs/virtualization.txt View File

@ -34,16 +34,3 @@ over baremetal functionalities.
TODO: difference between sandboxed and virtualized software execution env
You can use the script below to generate blabla
#!/bin/sh
UUID=$(uuidgen)
cat << EOF
<hostdev mode='subsystem' type='mdev' managed='no' model='vfio-pci' display='on'>
<source>
<address uuid='$UUID'/>
</source>
</hostdev>
EOF

BIN
secrets/assets/emet-selch.md View File


BIN
secrets/infrastructure/emet-selch/amaurot.nix View File


Loading…
Cancel
Save