[systemd-devel] FDE: UEFI/Secureboot solves main part / missing link is /boot encryption
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.
firmware->shim->bootloader/grub2->{manual
interaction/password}->LUKSdecryption->kernel/initrd
Every former part checks the following one until the kernel and
the initrd is protected by LUKS (AFAIK grub2 supports only LUKS VERSION1)
Last time I checked macOS (before APFS) - they use also "boot.efi"
to get the pass and decrypt EncryptedRoot.plist.wipekey. Both "boot.efi"
and EncryptedRoot.plist.wipekey are on the unencrypted partition ...
Just some thoughts,
Leon
Re: [systemd-devel] FDE: UEFI/Secureboot solves main part / missing link is /boot encryption
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! 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. Lennart -- Lennart Poettering, Berlin
[systemd-devel] troubleshooting Clevis
Hi guys. I have 'clevis' set to get luks pin from 'tang' but unlock does not happen at/during boot time and I wonder if someone can share thoughts on how to investigate that? I cannot see anything obvious fail during boot, moreover, manual 'clevis-luks-unlock' works no problems. many thanks, L.
Re: [systemd-devel] Prefix for direct logging
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] Prefix for direct logging
Hmm, changes to the service side (for prefix) would be a bit difficult at the moment. And moreover the journal is a bit luxurious where we get the timestamp, hostname, process name and it's PID. So I would like to have that luxury in the logs. I have a thought raised from your suggestion. Is it fine to have an extra service to each service (for that 40 services) where the new service runs "journalctl -f -u " and lets its stdout be connected to the respective log file?. This way we can take journal logs and put it in the respective log file. But a basic question is, would running 40-50 instances of journalctl impact the load? I will perform an experiment on that as well. -- Arjun On Tue, Sep 28, 2021 at 11:32 AM Mantas Mikulėnas wrote: > On Tue, Sep 28, 2021, 06:07 Arjun D R wrote: > >> Thank you Mantas for the details. >> How do you currently get the logs "every few seconds"? >> > Actually we have a script that will be triggered every 10 seconds. That >> script will run "journalctl -u " and redirect the output to the >> respective log file. We will run journalctl for around 40-50 services for >> every 10 seconds and redirect it to the respective log files. That may be a >> bad idea, but this is how we are collecting logs as of now. We need to >> separate the logs for every service and that's why we ended up with this >> implementation. >> > > So replace it with 40-50 instances of continuously running `[stdbuf -o0] > journalctl -f -u `. > > Although syslogd might be easier, since then you'd only need one process > doing the monitoring. (I know both syslogds can access journal fields like > _SYSTEMD_UNIT, but I don't know how, so usually I just filter by the > traditional "program name" and it does the job.) > > You could also have a custom daemon that reads from `journalctl -f -o > json` and writes to the appropriate text log... > > >> >> Ah, ok so StandardOutput:file: will allow the service to open >> the fd and directly connect it to the service stdout. >> > > Yes, so if you want timestamps they have to be provided by your service, > pretty much like how most services implement direct logging to files. > (Probably the only advantage of StandardOutput is that the service doesn't > need permissions to /var/log...) > >>
Re: [systemd-devel] troubleshooting Clevis
On Di, 28.09.21 12:26, lejeczek (pelj...@yahoo.co.uk) wrote: > Hi guys. > > I have 'clevis' set to get luks pin from 'tang' but unlock does not happen > at/during boot time and I wonder if someone can share thoughts on how to > investigate that? > I cannot see anything obvious fail during boot, moreover, manual > 'clevis-luks-unlock' works no problems. This is the systemd mailing list, not the clevis/tang mailing list. Please contact the clevis/tang community instead. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] fstab automount of a mdns samba share
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 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [systemd-devel] fstab automount of a mdns samba share
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/openmediavaultcifs 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. Julian but if I try to replace the IP address with odroidxu4.local, the mount will fail at boot. It appears that mdns is not working at the time the mount is attempted as running mount -a afterwards works just fine. What would be the proper way of setting this up? Thanks! Best regards, Julian
Re: [systemd-devel] fstab automount of a mdns samba share
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/openmediavaultcifs 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. Julian but if I try to replace the IP address with odroidxu4.local, the mount will fail at boot. It appears that mdns is not working at the time the mount is attempted as running mount -a afterwards works just fine. What would be the proper way of setting this up? Thanks! Best regards, Julian
Re: [systemd-devel] Prefix for direct logging
On Tue, Sep 28, 2021, 06:07 Arjun D R wrote: > Thank you Mantas for the details. > How do you currently get the logs "every few seconds"? > > Actually we have a script that will be triggered every 10 seconds. That > script will run "journalctl -u " and redirect the output to the > respective log file. We will run journalctl for around 40-50 services for > every 10 seconds and redirect it to the respective log files. That may be a > bad idea, but this is how we are collecting logs as of now. We need to > separate the logs for every service and that's why we ended up with this > implementation. > So replace it with 40-50 instances of continuously running `[stdbuf -o0] journalctl -f -u `. Although syslogd might be easier, since then you'd only need one process doing the monitoring. (I know both syslogds can access journal fields like _SYSTEMD_UNIT, but I don't know how, so usually I just filter by the traditional "program name" and it does the job.) You could also have a custom daemon that reads from `journalctl -f -o json` and writes to the appropriate text log... > > Ah, ok so StandardOutput:file: will allow the service to open > the fd and directly connect it to the service stdout. > Yes, so if you want timestamps they have to be provided by your service, pretty much like how most services implement direct logging to files. (Probably the only advantage of StandardOutput is that the service doesn't need permissions to /var/log...) >
