Repository navigation
Every ESP and control disk is mounted as FAT and nothing else - #224
Merged
Merged
Conversation
…ther filesystem under the partition's label, a link at a name root writes would carry the write to a disk or a file of the machine
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The on-system tools find an ESP by its GPT name on the system's own disk and mounted it without naming a filesystem, so the kernel took whatever was there. Nothing ties the name
kryptik-espto the FAT partition the firmware boots from.What that allows, to someone who can rewrite the disk or the stick while the machine is off:
kryptik-espis ext4 and holds links where the tools write:EFI/BOOT/BOOTX64.EFI.new,kryptik/committed-slot, the version files.boot-success(every boot, after the state partition is unlocked),kryptik-update,kryptik-recoverandkryptik-installthen write through those links as root in zone 0. The bytes are the tools' own, not the attacker's, but the places are the attacker's: a file inside the encrypted state partition, or another disk of the machine. An attacker with the machine in hand can already wipe the disk; this let them pick files inside the encryption, and from an install medium reach a disk the person did not name.Found by reading; not reproduced on a machine.
The change: every such mount is
mount -t vfat. FAT holds no links and no device nodes. The two mounts of a state partition the tool has just made or opened are namedext4in the same pass, so no mount of a device in these tools leaves its filesystem to be guessed.Files:
boot-success.sh,installer-run.sh,testctl.sh,kryptik-install.sh,kryptik-update,kryptik-recover. The ISO'sesp.imgis still mounted through a loop device (-o ro,loop), now as vfat.Tests:
tools/tests/mount-types.shfails on any mount in these tools that opens with its options, with a control that the pattern tells the two forms apart.tools/tests/boot-success.shexpects the typed commands. The install, update, integrity and boot suites exercise every one of these mounts on real media.The hardware report (#180) had the same fault in its two new mounts, and one that needs no patience: its boot service writes with nobody at the keyboard. It is fixed on that branch.