[systemd-devel] dm-integrity volume with TPM key?
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. I'd appreciate some pointers into the right direction. Cheers, Basti [1]:https://0pointer.net/blog/authenticated-boot-and-disk-encryption-on-linux.html
Re: [systemd-devel] Authenticated Boot and Disk Encryption on Linux
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. Anyway, the post is very interesting and I am looking forward to further developments. -- Miłego dnia, Łukasz Stelmach signature.asc Description: PGP signature
Re: [systemd-devel] [RFC] Switching to OpenSSL 3?
On Wed, 2021-09-15 at 16:06 +0100, Luca Boccassi wrote: > On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote: > > Heya! > > > > Some of the systemd developers have been discussing switching > > systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop > > support for older OpenSSL versions, as well as any GNUTLS/libgcrypt > > support. As you might have noticed OpenSSL 3.0 has been released > > recently, and for the first time resolves the GPL2 license > > incompatibility mess comprehensively, which opens this door to us. > > > > I personally care a lot about reducing the combinatorial explosion of > > deps a bit, and keeping our tree as maintainable as we can, with a > > single implementation of everything, not multiple, and no abstraction > > layers and such, and thus removing any compat kludges for other > > libraries or other library versions. > > > > Now, before we make a decision on this, I'd like to collect feedback > > on such a move. I know that there are some people who backpart new > > systemd onto old distros. How big would the pain be require porting > > OpenSSL 3, too, at the same time? > > > > (What's not up for discussion: for new additions to systemd we'll do > > only OpenSSL, and won't accept anything else. My question is really > > just about the stuff we aleady have, where we currently support > > GNUTLS/libcgrypt.). > > > > Anyway, I'd be interested in your thoughts about this. i.e. hear > > multiple takes, opinions, from differently people and positions? > > > > Thanks, > > > > Lennart > > To summarize in public what we discussed elsewhere: > > - OpenSSL 3 is licensed under Apache2 which is compatible with GPLv3 > but believed by many to be incompatible with GPLv2 > - systemd is mostly (L)GPLv2+, with no specific OpenSSL exception > clauses > - distributors of the built and linked binaries can safely and without > any reasonable doubt get over the perceived incompatibility by > declaring that the GPLv2+ binaries linked to OpenSSL are distributed > under GPLv3 > > The issue of course is with the "mostly" keyword. There are many > compat-headers backported from Linux UAPI headers, but they are covered > by the Linux syscall-note exception so they explicitly do not affect > the license of the binaries built with them. > There are however three GPLv2-only headers with no exceptions currently > included in all builds: > > - src/basic/ioprio.h which is in the process of being removed via > https://github.com/systemd/systemd/pull/20736 > - src/basic/linux/loadavg.h which is copied from > https://github.com/torvalds/linux/blob/master/include/linux/sched/loadavg.h > - src/shared/linux/bpf_insn.h which is copied from > https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_insn.h > > The third one to me seems the most problematic one, as it's fairly > complex and thus is unlikely to be perceived universally as exempt from > copyright. It is very annoying as it is clearly a "sample" source file, > which usually is intended to be reused liberally, and originally it was > without a license and was given GPLv2-only when the big SPDX refactor > happened. There are 5 companies or so holding copyright on that file, > so perhaps a quick avenue would be to seek their permission to dual > license it? BPF support in systemd is of course optional, so it could > instead be disabled everywhere so that the header is excluded at build > time, but it would be quite unfortunate Status update: all these issues have been solved. The first two headers have been removed, and the third one has been dual-licensed upstream. https://github.com/systemd/systemd/pull/20736 https://github.com/systemd/systemd/pull/20839 https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=d75fe9cb1dd062684c9fb8a4581738170365dc06 Therefore, we can say with certainty and no doubt whatsoever that systemd binaries can be distributed under (L)GPL-2-or-later and thus be compatible with Apache2, enabling linking with OpenSSL 3. The current plan is to avoid linking libsystemd.so to OpenSSL, so that the license of this library as distributed is not affected. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: [systemd-devel] Prefix for direct logging
Hi Lennart, Please help me understand how the journald is figuring out the PID of the log line. I believe, with the PID, the journald is able to get the remaining details (process name) from proc fs. I wonder how the journal is able to get the PID of the log contributor as there can be many processes spawned under a service! I am trying to understand the journald and it would be really helpful to know this magic. Thanks in advance, Arjun On Wed, Sep 29, 2021 at 12:14 PM Arjun D R wrote: > Hi Lennart, > > That's a good idea but still I would like to have the prefix as it is in > the journal . I understand it is impossible to bypass the journal and > expect the direct logging to be the same as journal entries. We can achieve > it through socket but still we cannot have the luxurious prefix as in > journal. > > I would better like to have a timer unit and corresponding logger unit. > Based on each service logging capability, let me decide the time. > > So it's like: > > Timer unit - To trigger the logger service for every n seconds (we can set > it as per the service logging range). > Logger Service - Run journalctl -u and the service is designed > to pass the stdout to the file (using StandardOutput) > > By this way, I can avoid the script running for every few seconds which > runs journalctl for almost 30+ services and redirect it to the respective > log files one by one at a moment which is impacting the load. > > Thanks for the help. > > -- > Arjun > > On Tue, Sep 28, 2021 at 7:06 PM Lennart Poettering > wrote: > >> On Mo, 27.09.21 15:40, Arjun D R (drarju...@gmail.com) wrote: >> >> > Hi Folks, >> > >> > Currently we are using systemd-journald for service logging. We run >> > journalctl for a bunch of services and redirect those to the custom log >> > files for every few seconds. This takes up the CPU for that particular >> > time period since we have lot of IO operations as well. We came to know >> > that systemd version v236+ supports direct logging >> > (StandardOutput:file:) to the custom log file by the service. >> I >> > would like to use that facility but we don't get the prefix that we >> used to >> > get when using the journal. >> > >> > Is there a way to prepare a custom patch locally to add the necessary >> > prefix to the stdout before writing to the custom log file? Is that a >> good >> > idea? Any other suggestions? >> >> >> You might define a socket unit 'prefixlogger@.socket' like this: >> >> [Unit] >> StopWhenUnneeded=yes >> >> [Socket] >> ListenFIFO=/run/prefixlogger.fifo.%i >> Service=prefixlogger@%i.service >> >> And then a matching service 'prefixlogger@.service': >> >> [Service] >> StandardInput=socket >> StandardOutput=file:/var/log/foo.log.%i >> ExecStart=sed -e 's/^/foo:/' >> >> And then in the services that shall run with this: >> >> [Unit] >> Wants=prefixlogger@%N.socket >> After=prefixlogger@%N.socket >> >> [Service] >> ExecStart=/my/service/binary >> StandardOutput=file:/run/prefixlogger/fifo.%N >> >> (This is all untested, might need some minor changes to actually work, >> but you get the idea). >> >> So what this does is this: first we define a little socket service >> that can be initialized easily a bunch of times: it listens on a FIFO >> in the fs and everything it reads from it it writes to some log >> file. The service is just an invocation of "sed" with standard input >> being the fifo and standard output being the log file to write to. >> >> You then use it by using StandrdOutput=… in your main unit, to connect >> its stdout/stderr to that fifo. Also, you add deps so that each time a >> service that tneeds this starts the log prefix service socket for it >> starts too. >> >> Lennart >> >> -- >> Lennart Poettering, Berlin >> >
Re: [systemd-devel] FDE: UEFI/Secureboot solves main part / missing link is /boot encryption
On Mi, 29.09.21 12:47, Leon Fauster (leonfaus...@googlemail.com) wrote: > > Encryption is not authentication. > > > > Not sure why you would encrypt your boot loader though? The boot > > loader code is hardly a secret, is it? It's the same for everyone and > > open source. > > > > And with which key? a key the user has to type in? how does that help? > > it means the user is queried three times for a pw? once by grub, once > > by cryptsetup and once when logging in? That's not an improvement! > > I think was partly misunderstood. Le me rephrase it. My motivation was > just a thought about one step in the implementation (in the context > of UEFI), that has a huge benefit. Speak, protecting the initrd. Thats the > start point. Well, it encrypts the initrd (which I am not interested in), and it doesn't authenticate it (which I want), and all that with an interactively acquired key (which I don't want). Maybe that solves your specific problem set — but it doesn't solve any of the issues I am trying to address. > Yes, enc != auth - but while speaking about authentication. Dracut > could enroll the signature of the initrd into the allow db (EFI). > So, grub2 could check both, the kernel and the initrd and making the > above encryption completely obsolete, thought. Well, my proposal suggests just including the basic initrd in the kernel image. The kernel's signature would then also validate this basic initrd. My focus is that this kernel/initrd signing happens during build time, not at install time, i.e. the secret signature keys should be held by the building party only, not by the local instalations. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] FDE: UEFI/Secureboot solves main part / missing link is /boot encryption
On 28.09.21 23:13, Lennart Poettering wrote: On Di, 28.09.21 19:44, Leon Fauster (leonfaus...@googlemail.com) wrote: Hallo Lennart, corresponding to your last post about FDE: On an EFI system - would an encrypted "/boot" or /boot on an encrypted "/" filesystem eliminate the mentioned main attack vector? The whole chain would be authenticated. Encryption is not authentication. Not sure why you would encrypt your boot loader though? The boot loader code is hardly a secret, is it? It's the same for everyone and open source. And with which key? a key the user has to type in? how does that help? it means the user is queried three times for a pw? once by grub, once by cryptsetup and once when logging in? That's not an improvement! I think was partly misunderstood. Le me rephrase it. My motivation was just a thought about one step in the implementation (in the context of UEFI), that has a huge benefit. Speak, protecting the initrd. Thats the start point. Shim verifies the boot loader signature which is GRUB 2, right? The boot loader is on the EFI partition without encryption, right? Grub verifies the kernel signature, right? So, having the initrd on one encrypted partition would improve the current situation. The interactivity of entering the password is a further detail that needs attention but is left aside here. Yes, enc != auth - but while speaking about authentication. Dracut could enroll the signature of the initrd into the allow db (EFI). So, grub2 could check both, the kernel and the initrd and making the above encryption completely obsolete, thought. My blog story is an attempt to do things cleanly: i.e. authenticate what needs authentication, and do so in a way that doesn't require interactivity. The ultimate goal is that servers and embedded devices can boot up entirely unattanded in safe way, and that desktop machines only query the user once, and that the authentication the user does unlocks the user's actual data. Sure, that's the goal! -- Leon
Re: [systemd-devel] Prefix for direct logging
Hi Lennart, That's a good idea but still I would like to have the prefix as it is in the journal . I understand it is impossible to bypass the journal and expect the direct logging to be the same as journal entries. We can achieve it through socket but still we cannot have the luxurious prefix as in journal. I would better like to have a timer unit and corresponding logger unit. Based on each service logging capability, let me decide the time. So it's like: Timer unit - To trigger the logger service for every n seconds (we can set it as per the service logging range). Logger Service - Run journalctl -u and the service is designed to pass the stdout to the file (using StandardOutput) By this way, I can avoid the script running for every few seconds which runs journalctl for almost 30+ services and redirect it to the respective log files one by one at a moment which is impacting the load. Thanks for the help. -- Arjun On Tue, Sep 28, 2021 at 7:06 PM Lennart Poettering wrote: > On Mo, 27.09.21 15:40, Arjun D R (drarju...@gmail.com) wrote: > > > Hi Folks, > > > > Currently we are using systemd-journald for service logging. We run > > journalctl for a bunch of services and redirect those to the custom log > > files for every few seconds. This takes up the CPU for that particular > > time period since we have lot of IO operations as well. We came to know > > that systemd version v236+ supports direct logging > > (StandardOutput:file:) to the custom log file by the service. I > > would like to use that facility but we don't get the prefix that we used > to > > get when using the journal. > > > > Is there a way to prepare a custom patch locally to add the necessary > > prefix to the stdout before writing to the custom log file? Is that a > good > > idea? Any other suggestions? > > > You might define a socket unit 'prefixlogger@.socket' like this: > > [Unit] > StopWhenUnneeded=yes > > [Socket] > ListenFIFO=/run/prefixlogger.fifo.%i > Service=prefixlogger@%i.service > > And then a matching service 'prefixlogger@.service': > > [Service] > StandardInput=socket > StandardOutput=file:/var/log/foo.log.%i > ExecStart=sed -e 's/^/foo:/' > > And then in the services that shall run with this: > > [Unit] > Wants=prefixlogger@%N.socket > After=prefixlogger@%N.socket > > [Service] > ExecStart=/my/service/binary > StandardOutput=file:/run/prefixlogger/fifo.%N > > (This is all untested, might need some minor changes to actually work, > but you get the idea). > > So what this does is this: first we define a little socket service > that can be initialized easily a bunch of times: it listens on a FIFO > in the fs and everything it reads from it it writes to some log > file. The service is just an invocation of "sed" with standard input > being the fifo and standard output being the log file to write to. > > You then use it by using StandrdOutput=… in your main unit, to connect > its stdout/stderr to that fifo. Also, you add deps so that each time a > service that tneeds this starts the log prefix service socket for it > starts too. > > Lennart > > -- > Lennart Poettering, Berlin >
