All fles inside initrd filesystem are root-only readable

[oldium]

I am working on disk unlocking by TPM 1.2 integration for Clevis and I have faced strange behaviour caused by file created by Calamares on fresh Kubuntu 24.10 installation:

calamares/src/modules/initramfs/InitramfsJob.cpp

Lines 44 to 50 in 5ec934d

	static const char confFile[] = "/etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf";
	static const char contents[] = "UMASK=0077\n";
	if ( Calamares::System::instance()->createTargetFile( confFile, QByteArray( contents ) ).failed() )
	{
	cWarning() << Logger::SubEntry << "Could not configure safe UMASK for initramfs.";
	// But continue anyway.
	}

This code creates a file /etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf with UMASK=0077 with intention to create /boot/initrd* files root-only readable to prevent reading the sensitive content by users.

Side note: the “prevention” applies only for remotely logged in users, because you can get the /boot file content easily with physical disk access or with access to boot menu.

The side effect of the change is that all files created inside the prepared initrd filesystem are root-only readable, so when I try to run tcsd (daemon required to use TPM 1.2 module), which forces switch to tss user/group when started, it cannot access anything on the filesystem, like reading /etc/hosts or even the libraries required for running it like /usr/lib/x86_64-linux-gnu/libgcc_s.so.1.

Workaround: When I delete the file calamares-safe-initramfs.conf, everything works.

The trousers package with tcsd daemon is unmaintained as it seems, there are bugs addressed only in distro patches. The tcsd opens a TCP socket for requests (it can be accessed locally and when configured also remotely). The changes that forced tcsd to run under tss user were security fixes.

Workaround on my side: I can trick tcsd by LD_PRELOAD library to think it succeeded with setuid/setgid, but still run under root. I can disable remote access by ensuring that the tcsd configuration copied into initrd environment does not allow it (tcsd then listens on localhost). This way the tcsd will run under root, listen on localhost only and it should be hopefully safe. But I see this as a last-chance to get it working, because it works-around filesystem created with non-standard permissions.

[adriaandegroot]

I don't understand -- but initrd is really not my thing -- when the problem occurs. Why does anything need to run at all with the filesystem from initrd? If making the initrd umask 077 isn't a solution, what do you propose? We don't want to turn that off everywhere again, so maybe carefully listing ".. and these things need to be readable for more purposes .." would work.

[oldium]

I don't understand -- but initrd is really not my thing -- when the problem occurs. Why does anything need to run at all with the filesystem from initrd?

The reason is to run the tcsd daemon from Trousers project to be able to unlock the root partition with the password encrypted by TPM 1.2 chip by Clevis.

If making the initrd umask 077 isn't a solution, what do you propose? We don't want to turn that off everywhere again, so maybe carefully listing ".. and these things need to be readable for more purposes .." would work.

I propose to do what was intended in the original bug report - set the file permissions in /boot only. But it looks like the actual issue is in initramfs-tools - they call umask "${UMASK}" very early. It looks like they chose the quick-and-dirty solution, so they are not protecting the temporary directory and the target file, they simply set umask before creating anything, so all files (including the ones inside initrd image) are affected. So if anybody is willing to create a bug report for Debian, that would be great 😉

I made a workaround to be able to run tcsd anyway (LD_PRELOAD trick), so we could possibly close this.