"[…] The key pair on TPM side is generated from so called null random seed per power on of the machine [1]. This supports the TPM encryption of the hard drive by adding layer of protection against bus interposer attacks. […]"
1️⃣4️⃣ Here's the 14th installment of posts highlighting key new features of the upcoming v256 release of systemd.
This one is going to be quick one. Previously, you had to specify a block device name when invoking systemd-cryptenroll, to specify which encrypted volume to enroll your PKCS11/TPM2/FIDO2 device to. This is now optional. If no device is specified, then the tool will now automatically look for the device behind the /var/ directory and operate on that.
This of course makes the tool a bit more comfortable to use, since you don't have to figure out the backing block device of your encrypted volume first. But it's actually a security measure too:
On Linux referencing block devices by their device names such as "/dev/sda" is a bit problematic when it comes to security, since these names are reused on unplug/replug. Thus, there's a good chance that various security-relevant operations executed on disks can be tricked, …
… by quickly removing one disk, and plugging in another, so that the device node goes away, and comes back under the same name, but suddenly referring to a different device.
There has been work on addressing this problem, specfically there's now a "diskseq" counter exposed on Linux block devices that changes on every media change and device unplug. Thus, if on first use of a device the diskseq number is stored away, and then verified on each subsequent operation it's possible to…
… detect such tricks, and refuse operation. In systemd we thus started to make more and more use of diskseq, for example via /dev/disk/by-diskseq/ device symlinks, or by referencing block devices via their diskseq numbers whenever possible. This works is incomplete currently, there are gaps at various places (for example, there's no userspace API to query the diskseq number from a mounted file system that is backed by a block device).
By automatically detecting the right block device the attack window for enrollment operations becomes a lot smaller, and once the last gaps in the diskseq kernel apis are fixed we can fully lock down things so that we can guarantee that it's really the right device we operate on and not some trick device.
You might wonder why we are derive the backing device of /var/ rather than the root file system for this automatic mechanism: that's because we generally focus on two ways to set up a system:
you have a fully encrypted root fs, with /var/ being placed on the root fs too
you have an immutable root fs, but /var/ is mounted writable.
In both these cases using /var/ as the path to search the backing block device for will work, while using / instead would not work for the 2nd case.
Also note, that this mechanism is automatically disabled when a destructive operation is used (i.e. an existing key slot shall be wiped), for robustness reasons.
1️⃣3️⃣ Here's the 13th installment of posts highlighting key new features of the upcoming v256 release of systemd.
ssh is widely established as the mechanism for controlling Linux systems remotely, both interactively and with automated tools. It not only provides means for secure authentication and communication for a tty/shell, but also does this for file transfers (sftp), and IPC communication (D-Bus or Varlink).
@NekkoDroid So there's a programmable rate limit on socket units. If you hit that too often we assume that something is wrong (i.e. that the service in question dies quickly after activation and never can process its connections). Hence, in order to not consume unbounded CPU we will eventually give up trying to activate the service. This safety feature can be seen as a DoS, if there simply are very high amounts of connections, the rate limit is hit too after all, it cannot…
@NekkoDroid …distinguish between very high number of attempts because of misconfiguration or because of valid connection attempts.
Now, the this ratelimit was configurable since a long long time, people just never bothered to. You can simply turn it off in the socket unit via TriggerLimitIntervalSec=/TriggerLimitBurst=.
So, the DoS never really was a DoS, it was at best a misconfiguration.
With v255 we added a separate ratelimit to socket units that behaves differently, btw.
@NekkoDroid Specifically, there's now PollLimitIntervalSec=, PollLimitBurst=. If this rate limiting is hit, then the effect is not that the socket unit will be put in a failed state, but instead we'll just stop watching the socket for the rest of the time window. Once the time passed we'll start watching again. This basically means, that if the system is hit with a flood of connection attempts, we'll pause processing them for a while, and then return processing them after the configurable…
With that in effect I think we should be really safe and robust against DoS, because we actually never deny service, but at the same time we also don't let our CPU use grow unbounded.
@pid_eins Hi Lennart,
I saw in an article that you’re looking to replace sudo? I’m not sure how accurate that is but for brevity sake my ask is - Is it possible instead to keep sudo and just make run0 an alternative option?
Why I’m asking is because this would break so many scripts and packages. Pip and docker-compose changes have already done a lot of damage, let alone replacing this keyword which is used everywhere. Is there no way to modify sudo to achieve what you need instead?