Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Le 02/04/2018 à 17:00, Teddy Hogeborn a écrit : > So we'll do it the hard way, by > setting the system clock, like you did. I've just discovered a security issue with setting the date in the future : I have 2 Pis, serving both as a client and a server for each other. When I reboot one, the date is incorrect, and its mandos server fires up BEFORE the date is actually corrected by NTP. During this time, mandos-monitor displays a HUGE validity period for its clients (somehow calculated from the last ping but that's weird) and I assume it would then happily give the key to a client who has been offline for longer than authorized - turn on both machines, boot them anytime together, and they will happily give the key to each other. Of course this behaviour would permit defeating the whole system for severs without a properly set RTC. I think that some test should be added to the server to temporalizy "freeze" sending keys to a client which "last ping" is either in the future or in a remote past, or if the system date is somewhere in 1970... Or maybe too far away from the last recorded activity... It also raises the issue of "Mallory" playing with RTC settings in BIOS, or powering up a set of machines on a LAN with a rogue ntp server... ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C signature.asc Description: OpenPGP digital signature
Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Hi again Teddy, and than you so much for your kind and swift assistance, Le 02/04/2018 à 17:00, Teddy Hogeborn a écrit : > Would you mind trying the attached mandos-client.c? It tries to work > around the problem by, if the time is unset or is January 1970, setting > the time to the timestamp of the key file. If it works, I'll commit it > and probably make a new release with this code. I will try this and let you know. It may take me a few days though : First I will have to figure out how to patch and rebuild a Debian packages from sources. I haven't done it for years, and it wasn't Debian but RedHat by the time... So I have to learn. Second I'm a bit tired having spent all my 3-days week-end struggling with this and I need to take a bit of rest and do other things... Such as housekeeping ;-) But I will come back to you soon. BTW I looked for an Arch Linux version of Mandos, but unfortunately there is no existing port... There used to be an AUR package for the server, but it is unmaintained since 2015, and there's never been any for the client. Alas, because it's the client that I will need on Arch. It's possibly the big difference in the way the initramfs is built in Arch compared to Debian and post-install scripts that explains that. When I'm at ease with packaging for Debian, I may give a shot trying to build AUR packages for Arch. Let me thank you for this excellent tool : it is something that I have wanted for *years* and didn't know it existed ! It's extremely well conceived and it just does perfectly the job. So thank you. Have a nice evening. ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C signature.asc Description: OpenPGP digital signature
Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Okay I finally pinned it. By trying to run manually the GPG key import in the initramfs, I discovered that the issue was... THAT THE RASPBERRY PI HAS NO REAL TIME CLOCK ! /tmp/mandosULI7OC # path=/usr/bin/gpg gpg --enable-special-filenames --batch --no-sk-comments --homedir /tmp/mandos* --charset utf8 --enable-progress-filter --exit-on-status-write-error --impor t -- < /conf/conf.d/mandos/seckey.txt gpg: WARNING: unsafe ownership on homedir '/tmp/mandosULI7OC' gpg: key 7590231119DA2D24 was created 17619 days in the future (time warp or clock problem) gpg: key 7590231119DA2D24 was created 17619 days in the future (time warp or clock problem) gpg: key 7590231119DA2D24 was created 17619 days in the future (time warp or clock problem) gpg: key 7590231119DA2D24 was created 17619 days in the future (time warp or clock problem) gpg: key 7590231119DA2D24: no valid user IDs gpg: this may be caused by a missing self-signature gpg: key 7590231119DA2D24: failed to re-lookup public key gpg: Total number processed: 1 gpg: w/o user IDs: 1 gpg: secret keys read: 1 /tmp/mandosULI7OC # date -s 2018-04-02 Mon Apr 2 00:00:00 UTC 2018 /tmp/mandosULI7OC # path=/usr/bin/gpg gpg --enable-special-filenames --batch --no-sk-comments --homedir /tmp/mandos* --charset utf8 --enable-progress-filter --exit-on-status-write-error --impor t -- < /conf/conf.d/mandos/seckey.txt gpg: WARNING: unsafe ownership on homedir '/tmp/mandosULI7OC' gpg: /tmp/mandosULI7OC/trustdb.gpg: trustdb created gpg: key 7590231119DA2D24: public key "tethys" imported gpg: key 7590231119DA2D24: secret key imported gpg: Total number processed: 1 gpg: imported: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1 So I did a quick & dirty hack by creating the following file in /etc/mandos/network-hooks.d/dateset #!/bin/sh date -s 2030-01-01 exit 0 ...Regenerated the initramfs. AND NOW IT WORKS PERFECTLY ! I just now have to figure out if I'm happy booting with this dummy date (that gets fixed later on), or if I should take the pain to put some ntp inside the initramfs. Thanks again Teddy for all your help. CASE CLOSED as far as I'm concerned. ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C signature.asc Description: OpenPGP digital signature
Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
After a more thourough dive in GPGME logs, it is now crystal clear to me that the matter is that GPG is unable to import the key data that GPGME tries to feed into it at key import time. Here is the result of the GPG secret key import (working) inside the chroot : [GNUPG:] KEY_CONSIDERED . [GNUPG:] IMPORTED . [GNUPG:] IMPORT_OK 1 . [GNUPG:] IMPORT_RES 1 0 1 0 0 0 0 0 0 1 1 0 0 0 0 - Count : 1 - Imported : 1 - Sec Read : 1 - Sec Imported : 1 And now the failing one from initramfs : [GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0. - Count : 1 - No_User_ID : 1 - Imported : 0 - Sec Read : 1 - Sec Imported : 0 IMPORT_RES However it further seems to properly receive the encrypted data, but is unable to decrypt it because it has no keys. I have no clue about why, and what the difference can be, but I need a break for now as I have spent my entire sunday wrestling with this :-\ Thanks again for your help. ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C signature.asc Description: OpenPGP digital signature
Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Again :-) Le 01/04/2018 à 18:03, Teddy Hogeborn a écrit : > > To be precise, do you mean that the > /conf/conf.d/mandos/plugin-runner.conf file does not contain the line > --options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem > at the top? What, exactly, *does* it contain? Does it lack the > --groupid and --userid options too? Sorry, my mistake. I hadn't understood that the original config file had been doctored by scripts before insertion into the initramfs. So inside the initramfs (and chroot), its actual contents are : --options-for=mandos-client:--dh-params=/conf/conf.d/mandos/dhparams.pem --groupid=118 --userid=112 ## This is the configuration file for plugin-runner(8mandos). This # # Then follows the rest of the original config file, with my own contents : --options-for=mandos-client:--interface=eth0,--connect=:9601,--debug ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C
Bug#894495: mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Hi again, Le 31/03/2018 à 20:30, Teddy Hogeborn a écrit : > That is the important message. It means that it failed to decrypt the > data from the server using the GPGME library. In the past, this error > has been due to all the necessary GnuPG binaries not having been copied > into the initramfs image. I could make some further progress. The problem resides in GnuPG being unable to properly import the keys when running in the true initramfs, where it works running in the chroot. I've seen that Mandos creates a temporary directory in /tmp where it put files, in both situation. Then I turned on gpgme debug mode using : export GPGME_DEBUG='9:/tmp/gpgme.log' ...Before running the client, then checked and compared the outputs. (I won't attach the huge outputs because they obviously contain key material) I discovered that gpgme is first fed with a private key, sends it for GPG to import, then a public key, which it sends to GPG for import, and further on the decryption occurs. In the chroot, it ends by GPG replying with : [GNUPG:] DECRYPTION_OKAY. [GNUPG:] GOODMDC. [GNUPG:] END_DECRYPTION. But in the initramfs, it ends with : [GNUPG:] NO_SECKEY . [GNUPG:] BEGIN_DECRYPTION. [GNUPG:] DECRYPTION_FAILED. [GNUPG:] PROGRESS - 1189 0 B. [GNUPG:] END_DECRYPTION. Then I interested myself to the key imports. In the chroot, the secret key import replies : [GNUPG:] KEY_CONSIDERED . [GNUPG:] IMPORTED . [GNUPG:] IMPORT_OK 1 . Where in the actual initramfs, it replies : [GNUPG:] IMPORT_RES 1 1 0 0 0 0 0 0 0 1 0 0 0 0 0. So the issue is definitely GPG working in the chroot, and not working in the initramfs. I still have to try and figure out what difference could be a cause for this. Kind regards. ॐ -- Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C signature.asc Description: OpenPGP digital signature
Bug#894495: [tethys] mandos-client: Mandos client fails while booting but works from chroot into unpacked initramfs
Hello Teddy, and thanks for having taken the time to reply on a saturday :-)
Le 31/03/2018 à 20:30, Teddy Hogeborn a écrit :
>
> If practical, try the latest version, 1.7.19.
I have just installed and tested it. Alas, it exhibits the very same
behaviour...
> That is the important message. It means that it failed to decrypt the
> data from the server using the GPGME library. In the past, this error
> has been due to all the necessary GnuPG binaries not having been copied
> into the initramfs image.
I had guessed that. However, as it works running from chroot into an
unpacked copy of the initramfs, I guess that all the required files must
be present...
> First, when SSHing into the running system, make sure that /tmp is made
> writeable by the unprivileged _mandos user. This is fixed by the
> automatic scripts when booting, but if you are running things manually
> it might not be done. Simply run "chmod a=rwxt /tmp" in the initramfs
> file system.
That's already OK.
~ # ls -ld /tmp
drwxrwxrwt3 root root 0 Jan 1 00:00 /tmp
> Second, be aware that the instructions for running the client manually
> does not contain the optional --dh-params option (Usually passed with an
> argument of /etc/keys/mandos/dhparams.pem), but this option is used
> automatically by the boot scripts. Just to make sure, does it work when
> run manually with or without a chroot with this option? (Passing this
> option also makes the client startup quite a bit faster, speeding up
> debugging.)
I get the same result (working in chroot, but not working in actual
initramfs) in all environments, whether I use :
/lib/mandos/plugins.d/mandos-client
--pubkey=/conf/conf.d/mandos/pubkey.txt
--seckey=/conf/conf.d/mandos/seckey.txt --connect=[SERVER_IP]:9601
--debug; echo
or simply :
/lib/mandos/plugin-runner
I assume the latter starts the clients with the exact options from
/conf/conf.d/mandos/plugin-runner.conf ... and there is no --dh-params
option.
It also works with the manually added --dh-params option, either in the
normal system, or in the chroot. The only difference is that is the
normal system, the keys are located in /etc/keys/mandos , where in the
initramfs they are in /conf/conf.d/mandos
> Since GPGME is giving the error, and it has been a problem in the past,
> until it has beeen proved otherwise I suspect that the proper binaries
> are not present in the system, or that they are not runnable somehow.
Well, they are surely there as it works in the chrooted copy of initramfs...
> What does the "gpgconf" command output, in the normal system, in chroot,
> and at boot? Do the listed binaries all exist in all three systems,
> i.e. what is the output of this command?
>
> ls -laF $(gpgconf | awk -F: '{ print $3 }')
Inside the true running (and failing) initramfs :
/ # ls -laF $(gpgconf | awk -F: '{ print $3 }')
ls: /usr/lib/gnupg/scdaemon: No such file or directory
ls: /usr/bin/gpgsm: No such file or directory
ls: /usr/bin/dirmngr: No such file or directory
ls: /usr/bin/pinentry: No such file or directory
-rwxr-xr-x1 root root814996 Sep 18 2017 /usr/bin/gpg*
-rwxr-xr-x1 root root301848 Sep 18 2017 /usr/bin/gpg-agent*
Inside the (working OK) chroot copy :
/ # ls -laF $(gpgconf | awk -F: '{ print $3 }')
ls: /usr/lib/gnupg/scdaemon: No such file or directory
ls: /usr/bin/gpgsm: No such file or directory
ls: /usr/bin/dirmngr: No such file or directory
ls: /usr/bin/pinentry: No such file or directory
-rwxr-xr-x1 root root814996 Apr 1 07:04 /usr/bin/gpg*
-rwxr-xr-x1 root root301848 Apr 1 07:04 /usr/bin/gpg-agent*
In the "normal" system environment :
root@tethys:/# ls -laF $(gpgconf | awk -F: '{ print $3 }')
ls: impossible d'accéder à '/usr/lib/gnupg/scdaemon': Aucun fichier ou
dossier de ce type
ls: impossible d'accéder à '/usr/bin/gpgsm': Aucun fichier ou dossier de
ce type
ls: impossible d'accéder à '/usr/bin/dirmngr': Aucun fichier ou dossier
de ce type
-rwxr-xr-x 1 root root 814996 sept. 18 2017 /usr/bin/gpg*
-rwxr-xr-x 1 root root 301848 sept. 18 2017 /usr/bin/gpg-agent*
lrwxrwxrwx 1 root root 26 nov. 29 02:17 /usr/bin/pinentry ->
/etc/alternatives/pinentry*
Thank you very much for your kind asistance.
ॐ
--
Michel Bouissou <mic...@bouissou.net> OpenPGP ID 0xEB04D09C
signature.asc
Description: OpenPGP digital signature
