Landlock is a Linux Security Module (LSM) that enables unprivileged processes to create security sandboxes by restricting filesystem and network access. This document explains how Landlock works across kernel versions 6.1, 6.6, and 6.12, highlighting the evolution of features and practical examples for C application development.

• Unprivileged Access Control: Available to any process without special privileges
• Deny-by-Default: Only explicitly allowed actions are permitted

After setting up a Debian system which did not choose to use encryption during the installer, do these steps to encrypt sda3 partition so we have encrypted rootfs. Follow these steps when booted from another disk so we can off-line encrypt the rootfs:

1. Mount the btrfs rootfs to /mnt: mount /dev/sda3 /mnt
2. See the current size and devid of the btrfs filesystem (likely your filesystem will be devid 1): btrfs filesystem show --mbytes /mnt
3. Resize the filesystem to be 32MiB smaller so we can fit a LUKS header at the end of the partition: btrfs filesystem resize 1:-32M /mnt
4. Verify that the filesystem is actually smaller now: btrfs filesystem show --mbytes /mnt
5. Unmount the filesystem: umount /mnt
6. Check the filesystem to ensure no errors: btrfs check /dev/sda3
7. Encrypt the filesystem in-place (this will take a while): cryptsetup reencrypt --encrypt --verify-passphrase --reduce-device-size 32M /dev/sda3
8. Unlock the partition and name it "ssd" so we can mount it: `cryptsetup open /de

I have 2 Yubikeys which support the OpenPGP card capability. I want to have a robust GnuPG solution which allows me to store one of the keys in a safe place and to carry the other key with me daily on my physical keychain. I want to be able to fairly easily survive having the daily carry Yubikey be stolen, lost, or simply fail, by revoking those keys. I also want to be able to survive having the safely stored key fail by revoking those keys.

My original plan was to create a main key pair and 2 sets of encryption and authentication subkeys (4 total, 2 enc and 2 auth). The main key pair and one set of the encryption and authentication keys would be transferred to each Yubikey, so each Yubikey would share the common main key pair but have a different set of encryption and authentication subkeys. This turns out to be quite difficult to implement in a secure way due to how GnuPG's key-to-card functionality works. GnuPG expects if you transfer a key to a card that you want that key to only live on that card an

If the Linux kernel is compiled with the EFI stub loader (grep CONFIG_EFI_STUB /boot/config-*), then an EFI BIOS can boot the kernel directly, without the need for a bootloader like GRUB. This only requires that the kernel and the initrd exist on the EFI partition. The EFI boot menu and boot order can be managed with the command-line utility efibootmgr.

Copying the kernel image and initrd onto the EFI partition the first time is simple; the problem is keeping them up-to-date as the system is updated. In particular, lots of software packages can trigger the initrd to be rebuilt. The most recent kernel image and initrd need to be copied to the EFI partition every time they are updated.

The Debian Linux Kernel Handbook documents initramfs hooks, stating that "Packages for boot loaders that need to be updated whenever the files they load are modified must also install hook scripts in /etc/initramfs/post-update.d

I'm speaking into the Antlion ModMic Business connected to a Schiit Audio Fulla 3 USB sound interface and recorded by Audacity. I've set the mic input level about 3dB down which is about 89%. The microphone is 2 fingers width away from my face.

Now I'll toggle the in-line mute on and repeat the first 3 sentences of my review.

And now I've turned the mute back off. Hope this is helpful!

Create a bootable USB flash drive for generating and managing PGP keys. The keys will be generated and stored, encrypted, on the drive but then also transferred to Yubikeys for general use. Unless a Yubikey is lost or damaged, use of the flash drive should be extremely limited, if it is used at all.

A master certifying and signing (CS) key will be created, then sub-key signing (S), encrypting (E), and authenticating (A) keys will be created and signed by the C key. The C key will be archived with a password to the flash drive as well as transferred to a Yubikey 4. The SE&A sub keys will also be archived to the flash drive as part of the C key

In the longer term, I could see us having the possibility of leveraging Github more. Currently the trac.clfs.org web page has a perception of lacking in functionality, for instance it's very hard to tell someone how to go from the front page of trac to reading the current development version of the books online. Migrating everything from trac onto Github is an option in order to reduce maintenance burden of the trac instance. Additionally, instead of relying on the existing git hooks and existing clfs.org book building infrastructure, we could host the built books on Github pages and use something like Travis to do the building of that. Github pages can also be setup for the cross-lfs group on Github to take the place of what the trac instance has been used for in the past, mainly as a presence on the web and directing visitors on how to read/contribute to the books. The only aspect which I don't feel Github could serve all of the project's needs is with mailing lists.

I don't want to push for moving ev

To setup a YubiKey 4 and YubiKey 5 NFC to both authenticate myself for the following services:

1. U2F for Google Advanced Protection, GitHub, etc.
2. OpenPGP smart card (using same private key on both devices) for signing, encrypting, and auth (including SSH)
3. Yubico OTP (for some legacy services, etc)

Errors cause graphics output to lock up but mouse still moves, keyboard is dead, libvirt guests are OK, SSH access is OK. Can't shutdown cleanly over SSH, keyboard input doesn't work. Requires hard power-off via power button hold.

syslog looks like:

Dec 19 08:10:48 kaim-eeyore kernel: [88492.249393] radeon 0000:03:00.0: ring 0 stalled for more than 10248msec
Dec 19 08:10:48 kaim-eeyore kernel: [88492.249395] radeon 0000:03:00.0: ring 3 stalled for more than 10248msec
Dec 19 08:10:48 kaim-eeyore kernel: [88492.249398] radeon 0000:03:00.0: GPU lockup (current fence id 0x000000000007de00 last fence id 0x000000000007df67 on ring 3)
Dec 19 08:10:48 kaim-eeyore kernel: [88492.249402] radeon 0000:03:00.0: GPU lockup (current fence id 0x0000000000035dda last fence id 0x0000000000035e12 on ring 0)