Notices by Lennart Poettering (pid_eins@mastodon.social), page 2

@erincandescent cgroupfs actually exposes the cgroupid via ntha() and obha(). So yes, there's prior art for doing the same in pidfs. But it's a bit weird, because unlike cgroupfs pidfs is not an fs you can mount, hence you don't really have anything to invoke obha() on. You'd probably have to get a pidfd on your own pid first, before you can use it to use obha() to get to the pidfd you actually want to get to.

If you ask me, it's a fundamental requirement for any modern Linux-based OS to provide boot time integrity and as baseline provide unattended disk encryption bound to it. To make this happen, we added two essential TPM policy concepts to systemd-cryptenroll/systemd-cryptsetup:

1. Signed TPM PCR policies allow locking a disk to a public signing key of an OS vendor, ensuring that disks can only be unlocked if an OS signed by said vendor is booted.

2️⃣ Here's the 2nd installment of posts highlighting key new features of the upcoming v257 release of systemd.

In the past year and a bit I spent a lot of time on boot integrity (i.e. boot-time TPM measurements and policies built on top of them) of Linux, covering the boot from the boot loader (systemd-boot), over the UKI EFI stub (systemd-stub) through the initrd into early regular userspace, and then locking disk encryption to it.

There's a feature added to Linux 6.9 that I think people should become more aware of: there's finally an identifier for processes that doesn't wrap around as easily as UNIX pid_t PIDs do: the pidfd file descriptors have been moved onto their own proper file system (pidfs), which enabled at the same time unique inode numbers for them.

If you want a world-wide unique identifier for a process it makes sense to combine the pair of pid_t and pidfd inode number with the system's boot ID (i.e. /proc/sys/kernel/random/boot_id). This triplet is awesome, because for the first time we can uniquely identify a Linux process, globally in this universe.

In systemd we are making use of this heavily now: internally we always store a triplet of pid, pidfd, pidfd inode for referencing processes we manage and…

To query the inode number from a pidfd, you use a simple fstat() call, and look at the .st_ino field.

There's currently no way to get from a pidfd inode number directly to a process however. Hence, for now you always have to pass around a combination of classic PID and the new pidfd inode number. This can be safely and correctly be turned into a pidfd: 1. first acquire a pidfd from the PID via pidfd_open(). 2. Then fstat() the fd, and check if .st_ino matches the expected value.

These inode numbers are (at least on 64bit archs, i.e. anything modern) unique during the entire runtime of a system. And that's fantastic: there's finally a way how you can race-freely reference a process, with the ability to pass it around over any form of IPC, without risking that it suddenly starts to refer to some unintentended other process.

@josh after 15 years of TPMs and they becoming quite ubiquitious, I am still not seeing how they ever have been misused like this outside of theories and labs.

To me this appears to be mostly FUD from FSF/GNU.

I think if Linux OSes would actually start using TPMs properly, the net outcome for everyone would be *good*, and not bad. It would be much harder to gain persistence for an attacker, for example. And that's a massive benefit, for everyone.

@josh well, if you open up access to your logs (protected via measurements or not) to players you don't want to use them, it's kinda your own fault. Just don't do that. If you web browser passes quotes of your system to the web, it's a bug in the browser, not a problem of the TPM.

Every computing is dual-use, if you so will, I fail to see why this one should be more or less "dual-use" than anything else.

@duxsco yeah, I have doubts though that enrolling your own keys is something that can be made "just work" on general purpose PCs.

Yes, you can do it locally, if you know your hardware very well, or if you only care about VMs or so. But for the general population, I doubt self-enrolling is really an option. Too many problems given that hw extension cards provide signed firmware too.

@duxsco my own focus with systemd is definitely on providing generic components that help make any Linux based systems more secure. hence, I do care a lot about solutions that provide security and can be deployed on *generic* systems in the wild, without prior knowledge of what they provide or not. It's the "general population", or the broader IT ecosystem I care about, not some nerdy niche.

@mjg59 on my windows laptop here bitlocker locks to 0, 2, 4, 8, 9, 10, 11. Which I think is today's default on modern Windows. (I certainly didn't change it). PCR 7 is not included interestingly.

And I think the TPM stuff in windows pretty much works, no?

systemd-pcrlock tries to lock to even more PCRs by default (but might exclude some if there are measurements we don't recognize).

@awilfox some other comments:

we actually want to get rid of basename() use, and converted most uses over to our own path_extract_filename() (which is a bit more careful with the corner cases, and returns proper errors). If you port over the rest, we'd happily merge that and your basename incompat goes away.

@awilfox do i read properly from this that musl defines HOST_NAME_MAX to something other than 64? that's pretty broken, given that the kernel internally defines __NEW_UTS_LEN to 64, and thus that's the limit sethostname() is going to accept...

@awilfox the utmpx.h inclusion is upstreamable. we generally use the utmpx interfaces, since they appear to be the more modern ones. if some holdout code still uses utmp.h that should be fixed.

@awilfox Regarding split /usr/? What is this? 1999? All big distros have cleaned this up, which distros is this that still parties like it's 1999?

@awilfox your strerror_r() hack is not thread safe...

@awilfox i hope musl is not something people use for smaller/embedded/resource constrained system given it appears not to have a memory compaction (malloc_trim()) api? what is musl for then? kinda confused by that tbh, because i though that's what people use musl for?

Noone asked me, but if you are curious what my take on the recent sbat/SecureBoot kerfuffle is, I'll let you know anyway:

Frankly, I find SecureBoot ultimately pretty uninteresting tech. It casts a very wide net: it basically is a politically charged global allowlist, yet is useful as a very very lose denylist only, because it necessarily contains so so so much stuff. I think the value for security is relatively limited, because it it attempts to be universal, and hence can never be focussed.

…you really have to.

(I am trying to do my part on this of course, i.e. in systemd we measure a lot of things during boot now, and our FDE logic is hooked up with it.)

[That all said, I think SB might have some value if you enroll your own keys, which however can only work on very specific hw, and in VMs, but is probably not a solution realistic for general purpose PCs]