Re: [systemd-devel] fstab automount of a mdns samba share
W dniu 28.09.2021 o 10:34, Colin Guthrie pisze: Julian Sikorski wrote on 28/09/2021 07:37: W dniu 27.09.2021 o 16:38, François Cami pisze: Hi, On Mon, Sep 27, 2021 at 4:05 PM Julian Sikorski wrote: Hi list, I am trying to set up an automount of my samba share. It works when I go by the IP address, i.e. //192.168.0.220/julian /mnt/openmediavault cifs credentials=/home/julas/.credentials,uid=julas,gid=julas,vers=3.1.1,nobrl,auto 0 0 If this is in fstab, it's different from autofs/automount. Try adding _netdev to mount options. François Yes, this is in fstab. _netdev has helped, thanks! Would you mind explaining why it was not required when the IP address was being used? Network is needed either way. I suspect it's just a race condition related to timeouts etc. Perhaps the retry/timeout logic of mounting via IP is better than name lookup timeouts etc. _netdev is definitely the right fix here but depending on the portability of the machine (i.e. if it's a laptop) you may also want to look at x-systemd.automount option too to make it mount the path only when you try to access it rather than at boot. If not automount, then perhaps "x-systemd.mount-timeout=infinity,retry=" is also useful to make things more robust (although I'm not sure how these work with cifs). See man systemd.mount for some more info. HTHs Col Thanks for the explanation, it makes sense. This machine is a desktop so automount is not needed, I might use it for my laptop though. Best regards, Julian
Re: [systemd-devel] dm-integrity volume with TPM key?
Hello, thanks for quick reply, I guess this explains the lack of instructions ^^ As a workaround you'd use a regular file key for dm-integrity and put that on a TPM-protected partition, if I understand you correctly? I.e. you'd 1. enable secureboot (custom keys or shim), 2. bundle kernel & initrd into signed UEFI image for systemd-boot, 3. make / a LUKS-encrypted parition with systemd-cryptenroll, bound to the TPM (perhaps PCR 0 and 7) aund unlocked automatically at boot, 4. make /home a dm-integrity partition, with a regular keyfile from e.g. /etc/integrity.key (which is on the encrypted partition), and 5. use homed for LUKS-encrypted home areas on /home? Does this sound reasonable? That's actually not too hard to setup on Arch :) Cheers, Basti Am Donnerstag, dem 30.09.2021 um 10:15 +0200 schrieb Lennart Poettering: > On Mi, 29.09.21 21:53, Sebastian Wiesner (sebast...@swsnr.de) wrote: > > > Hello, > > > > "Authenticated Boot and Disk Encryption on Linux" [1] suggests to > > "make > > /home/ its own dm-integrity volume with a HMAC, keyed by the TPM" > > when > > using systemd-homed for user home directories. > > > > I'd like to try that but… how? I can use systemd-cryptenroll to > > make a > > encrypted volume with a TPM key, but how do I make a dm-integrity > > volume with a TPM key? I've gone through the manpage for > > integritysetup and did a few unsuccessful google searches, but I've > > not > > found any answer. > > It's not easy to find, because it doesn't exist. ;-) > > We have the TPM stuff in place, and we cover both cryptsetup + > veritysetup pretty nicely. We are still missing the final glue here > though. systemd-integritysetup + /etc/integritytab. The hard plumbing > problems are all solved, what's missing is just putting together the > porcelain for it. > > I had hope that libcryptsetup would support a mode where we can use a > LUKS2 superblock with only dm-integrity without dm-crypt (which would > give us proper key management for this thing). But the idea is not > attractive to the libcryptsetup people unfortunately, as it turns > out. > > My current thinking how I'd personally deploy this is actually not > necessarily by directly enrolling the HMAC key for dm-integrity with > the TPM, but instead just piggyback things to an otherwise protected > /etc/ or /var/. i.e. define a key file /etc/integrity.key (with a > fallback to /var/lib/integrity.key) or similar, that is used as > implicit HMAC key for all dm-integrity needs. Then, because (at least > in my idealized view) /etc or /var are authenticated territory (bound > to TPM) we get the property we want, indirectly. > > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] Authenticated Boot and Disk Encryption on Linux
Lennart Poettering 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
Re: [systemd-devel] Authenticated Boot and Disk Encryption on Linux
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. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] dm-integrity volume with TPM key?
On Mi, 29.09.21 21:53, Sebastian Wiesner (sebast...@swsnr.de) wrote: > Hello, > > "Authenticated Boot and Disk Encryption on Linux" [1] suggests to "make > /home/ its own dm-integrity volume with a HMAC, keyed by the TPM" when > using systemd-homed for user home directories. > > I'd like to try that but… how? I can use systemd-cryptenroll to make a > encrypted volume with a TPM key, but how do I make a dm-integrity > volume with a TPM key? I've gone through the manpage for > integritysetup and did a few unsuccessful google searches, but I've not > found any answer. It's not easy to find, because it doesn't exist. ;-) We have the TPM stuff in place, and we cover both cryptsetup + veritysetup pretty nicely. We are still missing the final glue here though. systemd-integritysetup + /etc/integritytab. The hard plumbing problems are all solved, what's missing is just putting together the porcelain for it. I had hope that libcryptsetup would support a mode where we can use a LUKS2 superblock with only dm-integrity without dm-crypt (which would give us proper key management for this thing). But the idea is not attractive to the libcryptsetup people unfortunately, as it turns out. My current thinking how I'd personally deploy this is actually not necessarily by directly enrolling the HMAC key for dm-integrity with the TPM, but instead just piggyback things to an otherwise protected /etc/ or /var/. i.e. define a key file /etc/integrity.key (with a fallback to /var/lib/integrity.key) or similar, that is used as implicit HMAC key for all dm-integrity needs. Then, because (at least in my idealized view) /etc or /var are authenticated territory (bound to TPM) we get the property we want, indirectly. Lennart -- Lennart Poettering, Berlin
