Liberté was 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
(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
Liberté Linux maintains persistent storage on an
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:
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:
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
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,
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 (
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.
Liberté Linux releases are signed with a designated PGP key (DSA-3072). During the build process, all downloaded files are automatically verified:
emerge-webrsync, which verifies snapshots against their PGP signatures (RSA-4096);
rsyncis not used since it lacks the verification mechanism
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