Question
Kali Live USB Encrypted Persistence Package Reproducibility Across Sessions
Ash Moss
0 reputation · 02 Sept 2021, 05:00 UTC
81.9K views1
Loading…
0 reputation · 02 Sept 2021, 05:00 UTC
The goal is to start a Kali live USB with an encrypted persistence partition and find the same development packages, files, and settings after every reboot. The persistence partition is unlocked with a passphrase at boot, and persistence.conf determines which directories survive.
It is unclear whether the installed package set can remain stable across Kali weekly and release images without manually recording and reinstalling packages. It is also unclear whether the default kali user's sudo access inside the persistent home directory creates a permission boundary that persists across sessions or weakens isolation between user and root.
34275 reputation · 02 Sept 2021, 11:26 UTC
All current Kali live image variants (default, light, everything, etc.) require the persistence boot parameter to activate encrypted persistence; none enable it by default.
There is no built-in package manifest or autopkg mechanism that reapplies a package list on each boot. Packages installed during a persistent session remain installed because the dpkg database and filesystem changes are stored in the persistent overlay.
The default kali user's passwordless sudo access (via /etc/sudoers.d/kali) remains consistent across reboots when /etc is included in persistence.conf.
Encrypted persistence uses a LUKS partition labeled persistence containing a persistence.conf file. A typical configuration that preserves packages, settings, and sudo rules includes:
kalilinux/home
/etc
/var/lib/dpkg
/usr/local
/root
When the persistence boot parameter is supplied, the initramfs unlocks the LUKS partition, mounts the overlay, and merges changes with the read-only squashfs root filesystem. File ownership and modes written during a session are preserved exactly as created.
Weekly/rolling Kali images ship updated base packages. Persistence preserves locally installed packages and configuration, but booting a newer live ISO presents the updated base system underneath the persistent overlay. This can cause library/ABI conflicts between the updated squashfs and persisted binaries in /usr/local or /opt.
If you need a reproducible package set across image upgrades, you must record the package list (e.g., dpkg -l | grep ^ii | awk '{print $2}' > packages.txt) and reinstall after switching ISOs, or use a configuration management tool.
The kali user's passwordless sudo is a live-image convenience shipped in /etc/sudoers.d/kali. Because /etc is persisted, the rule survives reboots unchanged. Persistence itself does not weaken isolation between user and root; the overlay merges changes at the filesystem level, so permissions remain as set during the session.
For production use, replace the passwordless rule with a standard sudoers entry requiring a password.
persistence parameter.persistence with a persistence.conf listing the directories above.sudo apt update && sudo apt install -y htop).persistence parameter.dpkg -l htop.cat /etc/sudoers.d/kali should show kali ALL=(ALL) NOPASSWD:ALL.persistence.conf includes /var/lib/dpkg and /usr/local; omitting them breaks package persistence.Are you using a weekly rolling ISO or a stable release ISO? This affects whether base-system version mismatches are likely when you update the live image.
Use comments to ask for clarification. Post a solution as an answer.
34,275 reputation · 02 Sept 2021, 05:48 UTC
Encrypted persistence in Kali Live is an overlay, not a frozen base image. With the persistence boot parameter and a LUKS partition labeled persistence, the system mounts the writable layer and applies /etc/persistence.conf to mirror selected paths from the read-only squashfs.
Installed packages survive reboots only because they are written to the persistent layer when persistence is active. The base squashfs still changes when you boot a newer weekly or release ISO, so library versions underneath the overlay can shift. There is no built-in package manifest that re-applies automatically on each encrypted-persistence boot.
Practical check: verify the boot entry contains persistence, inspect /etc/persistence.conf for the desired paths, and confirm a test package remains after a reboot with the passphrase unlocked.