[systemd-devel] Authenticated Boot and Disk Encryption on Linux

Lennart Poettering lennart at poettering.net
Mon Oct 4 12:43:17 UTC 2021


On Do, 30.09.21 18:54, Łukasz Stelmach (stlman at poczta.fm) wrote:

> > I have been working on code in homed to "balance" free space between
> > active home dirs in regular intervals (shorter intervals when disk
> > space is low, higher intervals when there's plenty). Also, right now
> > we already run FITRIM on home dirs on logout, to make sure all air is
> > removed then. I intend to also add logic to shrink to minimal size
> > then (and conversely grow on login again).
> >
> > This will only really work in case btrfs is used inside the homedir
> > images, as only then we can both shrink and grow the fs whenever we
> > want to.
>
> Interesting. Apparently[1] loopback driver punches holes in the image
> files and makes them sparse.

We currently issue FITRIM on logout (thus making the file sparse), and
on login we issue fallocate() to remove the holes again, and being
able to give disk space guarantees and disable overcommit during runtime.

> > [Encryption] isn't typically needed for /usr/ given that it generally
> > contains no secret data
>
> This isn't IMHO precisely true. Especially not for laptops. And I don't
> mean the presence of "hacking tools" you mentioned below. Even when all
> the binaries in the /usr all come from the Internet there are many
> different versions available. Knowledge which versions are running on a
> device may be quite valuable for an attacker to mount an remote on-line
> attack and extract data with malware.

Well, that's security through obscurity to some level. I know some
people are concerned about this, and they can encrypt that if they
really thinkg they must. But I doubt that this makes sense for the
cases where your OS payload comes in flatpaks, containers, sysexts,
portable services, …, i.e. is not written to /usr.

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list