Liberté is the first Linux distribution to ship with a Secure Boot-based trusted boot chain. The trusted chain starts with a KEK / DB CA root, which can be enrolled into UEFI Secure Boot firmware. The certificate signs GRUB EFI images (via an embedded intermediate certificate), which verify GRUB configuration files and the Linux kernel. Initramfs (embedded into kernel image) then verifies the compressed root filesystem image.
All verification failures are non-fatal, but need to be explicitly circumvented by the user, who must either disable Secure Boot, confirm verification failure in GRUB, or exit the debug shell in initramfs — depending on the chain stage at which the failure occurs.
With regular BIOS-based Syslinux boot, only the last stage (root filesystem verification) is performed. However, a minimal bootstrap
.iso image (lacking a compressed root filesystem) is provided, which can be burned to read-only media and used to boot a regular install of Liberté on writable media.
Liberté Linux maintains persistent storage on an OTFE volume accessible via
~/persist — a virtual partition file that is located on the boot media where Liberté is installed. This volume uses AES-256 cipher in XTS block mode, with SHA-512 header hashing. It is best to store all documents on this OTFE volume. In addition, Liberté provides automatic on-demand mounting of permanent and removable media at
/media. You are advised to employ extreme care when writing to such non-encrypted media. Specifically, it is recommended to avoid writing to the non-encrypted parts of the boot media, especially since the OTFE partition is fully resizable with
|Symmetric encryption||Asymmetric encryption/signing||Asymmetric signing digest|
Note that GnuPG tries very hard to not let you do what you want, especially w.r.t. limiting the generated asymmetric key size and the availability of asymmetric encryption algorithms. In this regard, GnuPG attempts to be a “software solution” like many Windows applications — but it is a non-interoperable command-line “solution” with many parameter switches. You might therefore consider evaluating other options, depending on your cryptographic needs.
Liberté explicitly configures selected applications and services to use Tor via its local proxy (where access to the proxy is additionally vetted), thus forcing applications to create connections to the proxy on the loopback interface (localhost). Netfilter IP firewall then realizes a default-deny policy on both incoming and outgoing external connections. An inadvertently leaked IP address or a direct connection attempt do not pose a problem with this approach. The only exception to this in Liberté is I2P, whose peer connections are transparently routed via Tor, because I2P does not support using proxies for this purpose, and because other methods (like dynamic library socksification) fail. Since I2P communication is visible to Tor exit nodes, this might pose a problem — however, I2P has been verified to not leak the system's IP address when used in hidden mode.
The following external traffic is explicitly allowed on the firewall:
- DHCP, and Tor external communication to HTTP(S) ports (no DNS is used)
- Rate-limited ping reply, the only possible response to uninitiated inbound traffic
- User-created VPN connections to relevant ports (servers must be specified as IPs, use
- Unsafe Browser's external communication (including DNS) for wireless hotspots registration
Note that I2P communicates with peers via Tor, providing additional anonymity, and enabling I2P to be used in most firewalled environments.
Loopback interface connections are also partially restricted:
- Only Tor and I2P can locally connect to the hidden service daemon
- Only main user and Privoxy can locally connect to Tor and I2P
- Only main user, cables daemon and HTP can locally connect to Privoxy
Some additional IPv4 protection is afforded by
sysctl kernel parameters.
DHCP transmissions are locked down: hostname transmittal, identification, ARP, and IPv4LL are disabled.
NTP is the only application that potentially must communicate in the clear — to a known server pool. NTP is not necessary for correct operation of Liberté, and it is currently turned off to prevent timestamp-based fingerprinting and MIM DoS attacks. Torified HTP adjusts the time very reliably — albeit with less precision. In general, Tor requires a correct computer clock to start up, but in Liberté this problem is circumvented using a consensus-based time estimate.
In order to connect to many wireless networks, a web login via transparently rerouted connection is required. Liberté allows to run a browser as a specially designated user, for which DNS access and network traffic to common wireless web registration ports are not filtered. To enhance Wi-Fi privacy, MAC addresses of wireless interfaces are randomized during boot.
Upon boot, the system is locked down by disabling the default root password (which is
liberte). Other accounts, including the main user, do not have a password. Also, most daemons drop superuser privileges immediately after starting, including Tor, I2P, Privoxy, NTP, HTP, D-Bus, nscd, PC/SC, and cables daemon. The root console (accessible when the X server is down) is still available for 2 minutes after boot for troubleshooting and other purposes. You can restore the password by running
usermod -U root or
passwd, and then
su to root elsewhere. Alternatively,
gentoo=root boot menu option has the same effect. Most of the root filesystem is read-only, and only selected directories are writable.
All the installed software is compiled with the Hardened Gentoo toolchain, which affords automatic protection against stack smashing attacks (SSP) and enables application address space layout randomization (ASLR) in the hardened PaX kernel. Grsecurity is also enabled.
An abrupt extraction of the removable boot device results in immediate RAM wipe and power-off. Upon normal reboot / shutdown sequences, RAM is also wiped to prevent cold boot attacks. Maximal RAM-clearing range is achieved by allocating memory after a kexec-based boot with a minimal kernel.
In X server environment, screen can be locked with
Win-L key sequence, or via panel menu. When the screen is locked, a logo image covers the whole screen, and mouse / keyboard are grabbed until the correct password is entered, followed by the
Enter key (during the first lock attempt, the user is queried for a password, and its hash is retained in the persistent storage). The VT Switch (
Ctrl-Alt-F*) and Zap (
Ctrl-Alt-Bksp) key sequences are permanently disabled in X server configuration, SysRq (
SysRq-*) kernel interaction key sequences are disabled, and ACPI power-off events are ignored until the screen is unlocked. Any tray notification events are similarly delayed.
Build and release security
Liberté Linux releases are signed with a designated PGP key (DSA-3072).
During the build process, all downloaded files are automatically verified:
- Initial Gentoo snapshots are verified against their PGP signatures (portage: RSA-4096) and signed checksums (stage3: RSA-4096, MD5 + SHA-1)
- Kernel patches are verified against their respective checksums (SHA-256)
- During incremental builds, Gentoo portage tree is updated using
emerge-webrsync, which verifies snapshots against their PGP signatures (RSA-4096);
rsyncis not used since it lacks the verification mechanism
- Individual downloaded packages are verified against checksums (RMD-160 + SHA-1 + SHA-256) that are kept in the previously verified Gentoo portage tree
- Custom ebuilds afford the same verification procedure as the ebuilds in portage
The fingerprints for all downloaded signing keys, as well as the kernel patches checksums, are located in the Liberté source tree.
NOTE: Currently, updates of SMART drives and I2P hosts lists are not verified, since the corresponding released updates are not signed. Instead, the structure of these lists is verified with regular expressions after each update. The I2P netDb router info files supplied with Liberté are analyzed using I2P's