Skip to Content
DocsAdmin GuideFamily Hardening

Family — Hardening checklist

Family enforces policies from inside the running OS: the daemon filters DNS, the kernel module blocks unapproved binaries, the screen recorder samples the active session. Everything we do assumes the machine actually booted Quazzar Cloud OS. A user who can boot a different OS — a live USB, single-user mode, or the same drive in a different chassis — sidesteps every one of those controls before Family even starts. This guide walks through closing those gaps at the boot level so the in-OS controls actually run.

Threat model

Apply the rest of this guide with the following expectations in mind.

What boot-path hardening protects against:

  • Replacing or deleting /usr/bin/quazzard while logged in as the supervised user.
  • Removing the quazzard.service unit so the daemon never starts on next boot.
  • Dropping into single-user / recovery mode from the GRUB menu.
  • Adding init=/bin/bash or systemd.unit=rescue.target to the kernel command line.
  • Editing the local Family blocklist by hand (it lives on a root-owned path).
  • Booting a live USB to mount the drive and edit the blocklist offline.

What it does not protect against:

  • Physically removing the drive and reading it on another machine without LUKS.
  • Tor, VPN, or HTTP proxies running inside the supervised user’s session — Family enforces at the DNS layer, so a transport that ships its own resolver bypasses it. An enforced VPN profile on a managed router is the right tool here.
  • A user who already has sudo / root. Root can flip every flag this guide sets. Supervised users must never be in sudoers.
  • OEM hardware backdoors (Intel ME, AMD PSP, vendor service partitions). These are out of scope for any user-space hardening.

LUKS full-disk encryption

LUKS encrypts the root partition so the drive is unreadable if removed and mounted elsewhere. Without it, anyone can pull the disk, mount it on another machine, and edit the Family blocklist or replace the daemon binary offline.

Ubuntu / Debian (installer)

On the “Installation type” screen, choose Advanced features and tick Encrypt the new installation for security. The installer will prompt for a passphrase that must be entered at every boot.

Existing Ubuntu install

Encrypting an existing root partition in place is not supported by the Ubuntu installer. The recommended path is to back up /home, /etc, and any application data, reinstall with the encrypted option ticked, then restore the backup. Community guides for in-place encryption with cryptsetup reencrypt exist but are fragile and not officially supported.

Fedora (installer)

On the Installation Destination screen, tick Encrypt my data before clicking Done. Anaconda will prompt for the passphrase before writing the partition layout.

Arch / manual

Format the root partition with cryptsetup luksFormat before laying down LVM or a filesystem:

cryptsetup luksFormat /dev/nvme0n1p2
cryptsetup open /dev/nvme0n1p2 cryptroot
# then pvcreate / mkfs on /dev/mapper/cryptroot

Make sure encrypt is in the HOOKS array in /etc/mkinitcpio.conf before filesystems, and that GRUB’s GRUB_CMDLINE_LINUX references the LUKS UUID.

What LUKS gets us

LUKS protects data at rest: once the drive is powered off, nobody without the passphrase can read it. That defeats the “pull the drive and edit the blocklist in a live USB” attack. It does not protect the running system — once the passphrase is entered and the OS is up, every in-OS attack still applies. LUKS is one layer, not the whole story.

BIOS / UEFI password

A BIOS / UEFI password stops a user from changing the boot order or booting from removable media. Without it, the supervised user can plug in a USB stick, hit F12 (or F2, Esc, Del — vendor-specific) at the splash screen, and boot any OS they like.

Vendor menus differ widely. The pattern is the same on all of them:

  1. Enter BIOS / UEFI setup at boot (Lenovo: F1 or Enter, Dell: F2, HP: Esc then F10, ASUS: Del or F2).
  2. Under Security, set the Administrator (sometimes called Setup or Supervisor) password. This is required to enter setup in the future.
  3. Under Boot, set the boot order so the internal drive is first. Optionally disable USB boot entirely.
  4. Under Secure Boot, enable it (recommended, not required). Secure Boot blocks unsigned bootloaders, raising the bar on live-USB attacks even if boot order is changed.

Write the BIOS password down somewhere a supervised user cannot reach. If you lose it, recovery on most consumer hardware means replacing the motherboard.

GRUB password

A GRUB password stops the bootloader menu from being edited at boot — the place where someone can press e and append init=/bin/bash to the kernel command line to get a root shell with no login prompt.

Generate a password hash:

grub-mkpasswd-pbkdf2

It prompts twice and prints PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.<long hex>. Copy the entire grub.pbkdf2.sha512… string.

Edit /etc/grub.d/40_custom and append:

set superusers="root"
password_pbkdf2 root grub.pbkdf2.sha512.10000.<hash>

Edit /etc/default/grub and ensure:

GRUB_DISABLE_RECOVERY=true

This removes the “recovery mode” entry that exists in some distros and drops to a passwordless root shell.

Regenerate the GRUB config:

# Debian / Ubuntu
sudo update-grub
 
# Fedora / RHEL
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

After this, editing any menu entry (e key) or dropping to a GRUB command line (c key) prompts for the root GRUB password. Booting the default entry still works without a password, so the machine still comes up normally. Combined with GRUB_DISABLE_RECOVERY, this closes the single-user-mode and kernel-arg-override paths.

Daemon binary protection (chattr +i)

The Quazzar Debian / RPM package marks the daemon binary and unit file immutable at install time so a non-root supervised user can’t remove or replace them. The postinst script runs:

chattr +i /usr/bin/quazzard
chattr +i /lib/systemd/system/quazzard.service

This is automatic — there is nothing the operator has to do by hand. The matching prerm script clears the flag before upgrades or uninstalls (chattr -i …) so apt upgrade and apt remove work normally.

Only root can lift the immutable flag. A supervised user cannot rm the binary, cannot redirect the unit file, and cannot replace either with a forged copy — even with write access to the directory.

Filesystem support. The immutable flag is a Linux extended attribute. It is supported on ext2 / ext3 / ext4, xfs, and btrfs. It is not supported on ZFS or some FUSE-mounted filesystems. The postinst tolerates the chattr failure and continues — the binary is still installed, just without the immutable flag. If the postinst logs chattr: Operation not supported, the rest of this checklist still applies, but the daemon binary itself is no longer tamper-resistant. Consider hosting /usr on a supported filesystem if Family is your primary use-case.

Verify the flag is set:

lsattr /usr/bin/quazzard

You should see an i in the flag column (e.g. ----i---------e------- /usr/bin/quazzard). If the i is missing, the postinst either didn’t run or your filesystem doesn’t support it. The Family device card in the Control Panel will not catch this — verify on every node by hand.

Hardening attestation

The Control Panel exposes a hardening attestation page at Settings → Family → Hardening with three checkboxes: LUKS full-disk encryption enabled, BIOS / UEFI password set, GRUB password set. A local admin (or the supervised user, if you trust them with the disclosure) ticks each box as the corresponding step is completed. The CP surfaces the attested count on the device card as a chip:

Family — 2/3 hardened

This is purely informational. Ticking a box does not enforce anything — Family has no way to verify from inside the OS whether the drive is LUKS-encrypted or whether the BIOS has a password set. The chip is there so a fleet operator scanning device cards can spot nodes that haven’t completed the checklist, not as a security control on its own. The attestation state is stored on the CP and replicated to the node, so it survives daemon reinstalls.

What we can’t fully prevent

Even with every step above, a few attacks remain:

  • Booting from USB. Mitigated only by the BIOS password and Secure Boot. A motivated user with a paperclip and the CMOS battery can defeat the BIOS password on most consumer hardware. Treat this as raising-the-bar, not airtight.
  • Physically removing the drive. Mitigated only by LUKS. Once the drive is out of the chassis and the passphrase isn’t entered, the blocklist on disk is unreadable. Without LUKS, the drive can be edited offline in minutes.
  • Tor, proxies, or VPN inside the user’s session. Family enforces at the DNS and binary-execution layer of the supervised OS. Any transport that ships its own resolver (Tor’s SOCKS5 proxy, a VPN client with its own DNS, a browser with DNS-over-HTTPS) bypasses the DNS filter. Block these at the network egress — an enforced VPN profile on a managed router or a dedicated firewall is the right tool.
  • A user who already has root. Everything in this guide assumes the supervised user is unprivileged. root can chattr -i, edit GRUB, replace the binary, and disable the daemon. Supervised users must never be in sudoers and must never share a password with an admin account on the same machine.

Where to next

Security HardeningBackup Strategy