e8cafae818
Update install.sh Correct sshd service location. Fixes #35 Signed-off-by: funk-on-code <113871227+funk-on-code@users.noreply.github.com> |
||
---|---|---|
.github | ||
etc/unbound | ||
desktop_postinstall.sh | ||
install.sh | ||
LICENSE | ||
README.md | ||
update_grub.sh |
Introduction
This is my installer for Arch Linux. It sets up a BTRFS system with encrypted /boot
and full snapper support (both snapshotting and rollback work!). It also includes various system hardening configurations.
The script is based on easy-arch. However, it diverges substantially from the original project does not follow its development.
Visit my Matrix group: https://invite.arcticfoxes.net/#/#tommy:arcticfoxes.net
How to use it?
- Download an Arch Linux ISO from here
- Flash the ISO onto an USB Flash Drive.
- Boot the live environment.
- Connect to the internet.
git clone https://github.com/tommytran732/Arch-Setup-Script/
cd Arch-Setup-Script
chmod u+x ./install.sh
./install.sh
Snapper behavior
The partition layout I use allows us to replicate the behavior found in openSUSE 🦎
- Snapper rollback works! You will no longer need to manually rollback from a live USB like you would with the @ and @home layout suggested in the Arch Wiki.
- You can boot into a readonly snapshot! GDM and other services will start normally so you can get in and verify that everything works before rolling back.
- Automatic snapshots on pacman install/update/remove operations
- Directories such as
/boot
,/boot/efi
,/var/log
,/var/crash
,/var/tmp
,/var/spool
, /var/lib/libvirt/images
are excluded from the snapshots as they either should be persistent or are just temporary files./cryptkey
is excluded as we do not want the encryption key to be included in the snapshots, which could be sent to another device as a backup. - GRUB will boot into the default BTRFS snapshot set by snapper. Like on openSUSE, your running system will always be a read-write snapshot in
@/.snapshots/X/snapshot
.
Security considerations
Since this is an encrypted /boot
setup, GRUB will prompt you for your encryption password and decrypt the drive so that it can access the kernel and initramfs. I am unaware of any way to make it use a TPM + PIN setup.
The implication of this is that an attacker can change your secure boot state with a programmer, replace your grubx64.efi and it will not be detected until its too late.
This type of attack can theoratically be solved by splitting /boot out to a seperate partition and encrypt the root filesystem separately. The key protector for the root filesystem can then be sealed to a TPM with PCR 0+1+2+3+5+7+14. It is a bit more complicated to set up so my installer does not support this (yet!).