[systemd-devel] How to authenticate login using org.freedesktop.login1
Hi All,
I was trying to authenticate a user from a deamon running in my machine. And I
found systemd-login can be used.
I went through documentation for interface org.freedesktop.login1, but I am not
clear on how it can be used.
Lets assume that there is a deamon called xyz running in my device which has a
webserver component. And it receives a request to login from https side.
And once the deamon has username and password, I would like to invoke some dbus
calls to org.freedesktop.login1 to perform the authentication.
Assuming org.freedesktop.systemd1.Privileged("true"), I see that I can use
CreateSession and ReleaseSession from interface org.freedesktop.login1.Manager.
But I have some doubts:
* Is this recommended approach.
* I am not seeing an argument in CreateSession method that takes password,
what am I missing here?
Thanks in advance 😊
Regards,
Arun Lal K M
Re: [systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
On 23.05.2023 21:54, Felix Rubio wrote: Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot GPG is independent alternative method of verifying files and most certainly not a workaround (it was implemented in grub2 long before Secure Boot support). does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Kernel image has verifiable origin (it is signed by the same entity that provides your distribution). It is static and does not change on end user system which makes it possible to sign by maintainers of distribution by a secret key that is hopefully kept secret. initrd is volatile, it is usually generated on the same system where it should be verified which means the key to sign it must be kept on the same system as well. Which makes it more probable that secret key will be leaked if system is compromised. And leaked secret key allows installing an arbitrary malware as part of initrd. Measured boot does not have this problem. If you encrypt your root and only allow decrypting if initrd (and kernel and any other data used during boot) has known content then initrd will be implicitly verified and if it is changed system simply fails to boot. This does not require any key management or storing any persistent secret on end system. Downside is that it requires TPM (or some other tamper resistant way to store hashes) so not universally applicable. Thank you very much!
[systemd-devel] why systemd-boot (seems as everyone else) does not check the signatures of initramfs?
Hi everybody, I am trying to understand something, and after looking around I have not found any explicit answer. Maybe somebody in this list can shed some light on the matter? I have a laptop in which I am setting up the boot process through systemd-boot, and this works. Now, I'd like to give a try to enable Secure Boot so that the whole boot sequence is protected against tampering. As I am still learning about the technology, I prefer to land on the use of shim/MOK. For what I have read, the sequence should be: 1. Install a version of shim signed with MS keys. 2. On that same folder copy systemd-bootx64.efi, renamed to grubx64.efi (as shim seems to work only with Grub as 2nd stage loader). 3. Sign the kernel with the key for which the certificate has been enrolled in MOK. 4. Reboot, enroll the keys and... voila. So far, so good... until we hit the initramfs wall: the efi's and kernel signatures are verified, but not that of the initramfs. I have seen that grub2 does not do it (it relies in GPG signatures, in which seems to be a workaround), and I have not found any place stating that systemd-boot does it. I have seen however, some steering towards the use of UKI... but this comes with its own problems about out-of-tree kernel modules and so. So, the question is: why the kernel image gets verified but not the initramfs? Is this mandated by some standard, or is an engineering decision? Thank you very much! -- Felix Rubio "Don't believe what you're told. Double check."
Re: [systemd-devel] setting up systemd-boot with separate EFI and boot partitions
Thank you Lennart. When I separated the /boot from /boot/efi I formatted /boot partition with ext2. After reading your answer I reformatted it to FAT and... all works. Regards! --- Felix Rubio "Don't believe what you're told. Double check." On 2023-05-23 10:51, Lennart Poettering wrote: On Mo, 22.05.23 14:26, Felix Rubio (fe...@kngnt.org) wrote: I have installed arch linux recently, with systemd-boot as boot manager and the EFI partition mounted on /boot. I am wondering how can I mount the EFI partition on /boot/efi, while vmlinuz-linux and initramf remain in /boot? Currently in my /boot/loader/entries/arch.conf I have the following: title Arch Linux linux /vmlinuz-linux initrd /amd-ucode.img initrd /initramfs-linux.img options root=PARTUUID= rw On this setup, I guess amd-ucode.img must remain in /boot/efi, but how can I specify that vmlinuz-linux and initramfs-linux.img are in another partition, if possible at all? sd-boot is an EFI program that uses EFI APIs to access file systems, hence it only generally supports FAT. It will look in the ESP as well as in XBOOTLDR. Thus is you mark your /boot/ partition as XBOOTLDR and format it is vfat it should just work. Lennart -- Lennart Poettering, Berlin
[systemd-devel] Monotonic time went backwards, rotating log
Every time I reboot, when I first log in, journald ( 253.3-r1 ) complains that the monotonic time went backwards, rotating log file. This appears to happen because journal_file_append_entry_internal() wishes to enforce strict time ordering within the log file. I'm not sure why it cares about the *monotonic* time being in strict order though, since that will always go backwards when you reboot. I'm also not sure why the previous check that the boot ID has changed did not trigger. If it is intentional that journals be rotated after a reboot, could it at least be done without complaining about it?
Re: [systemd-devel] setting up systemd-boot with separate EFI and boot partitions
On Mo, 22.05.23 14:26, Felix Rubio (fe...@kngnt.org) wrote: > I have installed arch linux recently, with systemd-boot as boot manager and > the EFI partition mounted on /boot. I am wondering how can I mount the EFI > partition on /boot/efi, while vmlinuz-linux and initramf remain in /boot? > > Currently in my /boot/loader/entries/arch.conf I have the following: > title Arch Linux > linux /vmlinuz-linux > initrd /amd-ucode.img > initrd /initramfs-linux.img > options root=PARTUUID= rw > > On this setup, I guess amd-ucode.img must remain in /boot/efi, but how can I > specify that vmlinuz-linux and initramfs-linux.img are in another partition, > if possible at all? sd-boot is an EFI program that uses EFI APIs to access file systems, hence it only generally supports FAT. It will look in the ESP as well as in XBOOTLDR. Thus is you mark your /boot/ partition as XBOOTLDR and format it is vfat it should just work. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Reg: systemd boot up hung after sysroot.mount in initrd phase
On Mon, May 15, 2023 at 10:34 AM Lennart Poettering wrote: > > On So, 07.05.23 20:28, RAJESH DASARI (raajeshdas...@gmail.com) wrote: > > > Hi , > > > > We are issuing reboot with this command systemctl --no-block reboot > > and boot up is stuck at initrd phase , we are using dracut and > > systemd in initramfs phase. Boot up is stuck after sysroot.mount is > > executed(Issue is always reproducible), I have enabled debug logs by > > passing systemd.log_level=debug systemd.log_target=console to kernel > > command line , issue is disappeared and I also tried to enable the > > dracut debug logs rd.debug=1, issue is disappeared. Then I have added > > sleep 1 in the systemd-fsck-root.service , then the issue is not seen. > > So it looks like a timing issue. > > > > > > Starting [0;1;39msystemd-fsck-root.service[0m - File System Check on > > /dev/disk/by-label/rootfs... > > Finished [0;1;39msystemd-fsck-root.service[0m - File System Check on > > /dev/disk/by-label/rootfs. > > Mounting [0;1;39msysroot.mount[0m - /sysroot... > > EXT4-fs (vda1): mounted filesystem with ordered data mode. Opts: (null) > > Mounted [0;1;39msysroot.mount[0m - /sysroot. -> boot up stuck after this. > > > > > > We are using systemd version-251.13 and with systemd version-249.14 > > we didn't notice this. Is there any new issue with this version or Is > > there any known issue if not Could you please let me know how to debug > > this further. > > This is a very vague report. It doesn't specify which distro is even > used. With the short logs excerpt one cannot figure anything out. > > This looks a lot like an integration issue, i.e. something you shoul > first ask your distro about. > > Other than that, there's this: > > https://freedesktop.org/wiki/Software/systemd/Debugging/#diagnosingbootproblems > > Lennart > yes I agree that it is a vague report, Unfortunately I can't provide much logs also if the debug logs are enabled the issue is not seen. I am mostly looking for some inputs on debugging this further. since boot up is getting hung after sysroot.mount is mounted(mounting is successful and no file system related errors and no timeouts), and adding a delay of 1 second is fixing this issue, so it is hard for me to find where it is getting hung as i am not fully aware of the systemd execution flow at initramfs phase. Few symptoms of this issue are : 1) Issue is seen only when the VM is rebooted with systemctl --no-block reboot. (VM launched from openstack and it is based on fedora 37) 2) When we do the soft reboot multiple times issue is still present and VM is hung at bootup, but after a hard reboot node is able to boot up normally. 3) Issue gets disappeared with one second of sleep in systemd-fsck-root.service or also if the debug logs are enabled from either systemd or dracut. To me it looks like a race condition, but not sure on how to debug further. > -- > Lennart Poettering, Berlin
