So, there appears to be a free software project called "suckless". As I understand it's a group of people who don't like systemd very much. Which is totally fine. What is a bit questionable though is that they keep spamming me with unsolicited invites to their confs, … 1/4
… but I guess that's their kind of humour, and I can certainly tune my spam filter to match this kind of spam, too. What totally isn't fine though, is that these mails originate from a host called "wolfsschanze" (paste.fedoraproject.org/paste/3udw8~w6…), which appears to be the laptop a … 2/4
certain Laslo Hunhold works from (their conf organizer?). Don't they understand that adopting such a form of Nazi symbolism just makes it easier to discount their work? (BTW, just to mention this in this context since it fits into the milieu: … 3/4
The message has since been deleted from the Devuan archives (aren't those people usually against any form of "censorship"?), but the Internet Archive doesn't forget: web.archive.org/web/2019040415…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
@josefbacik To my knowledge none of btrfs/xfs/ext4 give any guarantees against rogue file systems. If you want to build an offline secure system its essential the storage is so simple and dumb that it has an absolutely minimal attack surface.
@josefbacik On fuchsia the bootloader already reads kernel+initrd from blobfs, and its straightforward, because the fs is so simple... I.e. it provides exactly what you need for an offline secure OS (i.e. storage of verifiably immutable blobs, referenceble by some short handle)
@josefbacik But not more. No file names, no complex allocations, and so on. On btrfs/xfs/ext4 otoh the attack surface is so big you'll have auch harder time to lock things down, so that an attacker cannot exploit the btrfs reader implementation. But of course, you are the btrfs guy, so my q:
On Linux `struct sockaddr_un` only accepts an AF_UNIX file system path of max length 108ch. Which ends up to be quite limiting for apps building socket paths from `$XDG_RUNTIME_DIR` and similar. So, here's a work-around to avoid this limit, and enjoy your AF_UNIX sockets with…
…full Linux path length: open the socket node first with `open(…, O_PATH)`. And then use the path `/proc/self/fd/<fd>` (with `<fd>` replaced by the fd number you just got) in the `struct sockaddr_un` structure. This you can use directly in connect(). Yay! That's only half the…
…story though, after all we also want to bind() to such a path. The work-around for that is a bit more involved: determine the parent directory of the AF_UNIX node you want to create. Then create a symlink under a random name in /tmp/, pointing to it.
What I find quite irritating about the whole TPM2 + Windows11 discussion, and the supposed advantage of Linux given that Linux generally doesn't use TPM2 is that that's hardly a good thing, but a big missed opportunity. The state of offline security on the…
…classic, traditional Linux distributions is sad. Even though we have all the building blocks for SecureBoot, TPM2, disk encryption, disk integrity checks in place, the way the typical Linux distributions use them is just sad. The only two facets typically deployed on typical…
…Linux installations are SecureBoot integrity checks covering the kernel image itself and then LUKS encryption covering the root fs. This leaves a major gap in between though: the initrd which is generated dynamically on the host and entirely unprotected, making it trivial to…
Unbelievable, just lost 6h of my life to Linux fs API "misdesign". So let's say you have a disk image file with an ext4 fs, it's read-only, you want to mount it read-only. So you read-only attach it to a loopback device (i.e. O_RDONLY open + LO_FLAGS_READ_ONLY). Because you are…
…extra careful you even check with BLKROGET and yes, it tells you: this block device is read-only. So you go on, and mount it read-only, i.e. mount() with MS_RDONLY. One would assume because everything in this chain was explicitly done read-only frickin' ext4 wouldn't modify…
… the original file. Ha, you are so naive, of course it does! All these read-only flags don't matter a thing, ext4 writes whenever it wants to. Read-only access is for wussies, real kernel code doesn't care about explicitly specified flags on every level. ext4 doesn't, …