Lennart Poettering <lenn...@poettering.net> writes: > On Mi, 29.09.21 21:09, Łukasz Stelmach (stl...@poczta.fm) wrote: >> Hi, Lennart. >> >> I read your blog post and there is little I can add regarding >> encryption/authentication*. However, distributions need to address one >> more detail, I think. You've mentioned recovery scenarios, but even with >> an additional set of keys stored securely, there are enough moving parts >> in FDE that something may go wrong beyond what recovery keys could >> fix. To help users minimise the risk of data loss distributions should >> provide backup tools and help configure them securely. >> >> This is of course outside of the scope of your original post, but IMHO >> it is a good moment to mention this. >> >> * Well there is one tiny detail. >> >> You noted double encryption needs to be avoided in case of home >> directory images by storing them on a separate partition. Separating >> /home may be considered a slight inefficiency in storage usage, but >> using LVM to distribute storage space between the root(+/usr) and /home >> might help. However, to best of my knowledge (which I will be glad to >> update) there is no tool to dynamically and automatically manage storage >> space used by home images. In theory the code is there, but UX of >> resize2fs(8) and dd(1) is far from satisfying and I am not entirely sure >> what happens if one truncates (after resize2fs, which will work) >> a file containing a mounted image. >> >> The first solution that comes to my mind is to make systemd-homed resize >> home filesystem images according to some policy upon locking and >> unlocking. But it's not perfect as users would need to log out(?) to >> trigger allocation of more storage should they fill their home >> directory. > > 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. This should allow for overcommit on the
/home fs. I don't know at the moment how would the loopback driver (and
the overlying fs) react in case it can't fill the holse punched earlier
because other users took all the space on /home. As you can see below
this works with ext2 as an fs.
--8<---------------cut here---------------start------------->8---
root@zniczek:~# dd if=/dev/zero of=img1 bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB, 10 MiB) copied, 0.0136506 s, 768 MB/s
root@zniczek:~# ls -ls img1
10240 -rw-r--r-- 1 root root 10485760 Sep 30 18:40 img1
^^^^^
root@zniczek:~# mke2fs img1
mke2fs 1.46.2 (28-Feb-2021)
Discarding device blocks: done
Creating filesystem with 10240 1k blocks and 2560 inodes
Filesystem UUID: 176248e1-4845-46e6-9f49-762ce9d0ea6b
Superblock backups stored on blocks:
8193
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
root@zniczek:~# ls -ls img1
140 -rw-r--r-- 1 root root 10485760 Sep 30 18:41 img1
^^^
root@zniczek:~# mount -o loop,discard img1 /mnt
root@zniczek:~# fstrim -v /mnt
/mnt: 9.6 MiB (10054656 bytes) trimmed
root@zniczek:~# ls -ls img1
76 -rw-r--r-- 1 root root 10485760 Sep 30 18:41 img1
^^
# dd if=/dev/urandom of=/mnt/foo bs=1M count=2
2+0 records in
2+0 records out
2097152 bytes (2.1 MB, 2.0 MiB) copied, 0.0155418 s, 135 MB/s
# ls -ls img1
92 -rw-r--r-- 1 root root 10485760 Sep 30 18:48 img1
^^
# sync
# ls -ls img1
2156 -rw-r--r-- 1 root root 10485760 Sep 30 18:48 img1
^^^^
--8<---------------cut here---------------end--------------->8---
BTW. You wrote:
> [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.
I don't have any hard numbers at hand, but I suspect with a plenty of
RAM most frequently used binaries will be decrypted and cached so the
CPU overhead is *propably* negligible.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?h=v5.10#n625
--
Miłego dnia,
Łukasz Stelmach
signature.asc
Description: PGP signature
