Post B7eQmnO3vudPFxqVdY by pid_eins@mastodon.social
 (DIR) More posts by pid_eins@mastodon.social
 (DIR) Post #B7eQmlZKh2SfcL6TvU by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       2️⃣2️⃣ Here's the 22nd post highlighting key new features of the recently released v261 release of systemd. #systemd261 #systemd In a fully image based OS, the right way to insert an executable to run on the system into the system is of course by placing it into one of images the OS is composed of. In secure systems this usually means in a disk image that contains an immutable file system (erofs or so) in a cryptographic envelope (verity is best, with a signature).With such a model the system…
       
 (DIR) Post #B7eQmm5EmPyxDI1xei by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       …will have some really nice properties: any executable can be traced back to its image, and thus the cryptographic signature of its file system and thus the vendor where the executable originated. Nice!But – in order to take benefit of the full security benefit of this model – it's also important to enforce that other ways to insert executables into the system are prohibited. Because if that's not prohibited then an attacker could still scp some binary to /tmp/ and run it from there.
       
 (DIR) Post #B7eQmnO3vudPFxqVdY by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       With v261 systemd ships with an (optional) BPF-LSM based security policy that can enforce a logic like this, via the new RestrictFileSystemAccess= knob in systemd.conf. If enabled executables can only run off dm-verity backed file systems, and attempts to run binaries from other file systems will be refused. This mechanism we plan to extend in future versions in order to both tighten the rules around this and make it more flexible. For example, ideally we wouldn't even allow mounting…
       
 (DIR) Post #B7eQmoTlsAnMdxWaAq by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       …file systems not backed by dm-verity, rather than just prohibit execution of binaries for them. (This requires some kernel changes, which is being worked on, but once that lands, we'll hook this up to systemd too). And on the other hand it makes sense to be this restrictive for the host, but maybe relax the rules for certain user name spaces down the tree, simply because OCI/docker containers geneerally have a "yolo" security model, i.e. are not backed by verity but by a frickin' unsigned…
       
 (DIR) Post #B7eQmqEbLXqi5URUo4 by pid_eins@mastodon.social
       0 likes, 0 repeats
       
       …tarball.(Oh and before you ask, the IPE LSM added to the kernel recently, can do something similar, but we believe BPF-LSM is the way to go for things like this, as it allows us to have tighter, more focussed rules in place, without having to change the kernel for every single tightening, but just for some)