Hi Wolfgang, On Sa 06 Jul 2019 13:33:51 CEST, Wolfgang Schweer wrote:
Hi Mike, On Fri, Jul 05, 2019 at 08:17:13PM +0000, Mike Gabriel wrote:Commits: f8f436e8 by Mike Gabriel at 2019-07-05T20:16:50Z debian/debian-edu-config.fetch-ldap-cert: Retrieve TJENER's PKI server certificate only once per host. With the intention of fixedly attaching a Debian Edu workstation to a specific Debian Edu network. This re-introduces the behaviour of fetch-ldap-cert (and thus, of Debian Edu workstations) in stretch and earlier. (Closes: #931413).Thanks for checking the SSL/TLS setup, very much appriciated.
URW. I needed to dive into it to see what is compatible between old and new Debian Edu versions while upgrading a customer's site to Debian Edu.
I had now time to look into this; here are my thoughts (and please correct me if I'm wrong):
Will do...
The intention had been to add LDAP to the already existing certificate generation setup to be able to validate the LDAP server certificate against the Debian Edu rootCA one (and to have everything in one place).
This is a very good approach. All further server certificates on a Debian Edu site should be generated against the Debian Edu rootCA, too. Good to have that! I haven't looked at the command set, yet, though.
I first used this condition that kept things like before (download the
certificate file once:
if [ ! -f $CERTFILE ] && [ -f /etc/nslcd.conf ] &&
Until I noticed that this setting would hit systems badly if a new
service would be added (a local administrator might want to add e.g.
freeradius, owncloud, radicale, whatever). The certificate would not be
renewed, certificate validation would fail.
I may be mistaken, but it feels like there is an error in reasoning here: While looking at fetch-ldap-cert [1] I saw that debian-edu-bundle.crt gets downloaded and the cert file for ldap.intern gets extracted. Whereas this is basically the old behaviour, IMHO, it would be sufficient to distribute the DebianEdu site's rootCA.crt file to the clients. If all server certificates get created on TJENER and signed against the same rootCA, the rootCA is all what clients need to have verified TLS conncetions against on-site Debian Edu servers/services.
[1] https://salsa.debian.org/debian-edu/debian-edu-config/blob/master/debian/debian-edu-config.fetch-ldap-cert#L43
I noticed, too, that the certificate wouldn't be available inside the
LTSP chroot if the default NBD method is used - unless the NBD image would
be rebuilt after the first boot of an LTSP server.
That's why I dropped the first condition, using only:
if [ -f /etc/nslcd.conf ] &&
Another error in reasoning... A diskless machine doesn't probably have any values/assets to protect, so why deploy the LDAP server cert at all to the diskless chroot? It is sufficient (and fully works) to retrieve the LDAP cert during the diskless machine's boot process.
- debian/debian-edu-config.fetch-ldap-cert ===================================== debian/debian-edu-config.fetch-ldap-cert ===================================== @@ -79,7 +79,13 @@ do_start() { case "$1" in start) - do_start + # do absolutely nothing, if this host is already "attached" to + # a Debian Edu network + if [ -e /etc/ssl/certs/debian-edu-server.crt ]; then + : + else + do_start + fi ;; stop) ;;If I understand this correctly, the LTSP chroot would never get the LDAP server certificate if someone sets up a new LTSP chroot on an existing LTSP server.
As said above, there is no need to add the LDAP cert into the chroot at all during its creation/upgrade. It works perfectly well to deploy the LDAP cert during diskless systems' startup. Of course, fetch-ldap-cert needs to run before any of the LDAP client services comes up.
From the bug report: 11:55 < sunweaver> I found the previous approach more charming and "secure".11:56 < sunweaver> in a world where GRUB is md5 protected, you would not be able to retrieve local data from the notebook.I figure this could de cracked in no time. A search on the web for 'root password reset' and afterwards (once they notice that Grub requires a password) for 'grub password reset' will show them how easy it is to get rid of this protection.
For 100% securing a Linux workstation, such as a Debian Edu workstation, you need:
* crypto file system(s) via TPM (student machines) or passphrase (teachers' personal
machines)
* grub passphrase protection (prohibits editing the grub menu manually)
* secure remote access (during runtime)
Please check so that we can have a good solution that works in all use cases.
Disallowing replacement of the LDAP server cert / (or maybe rootCA.crt) during reboot is _one_ measure to consolidate system access. We had that until stretch.
The grub passphrase protection is something we want to add for our school customers. So, that'd be another measure. We don't have that, yet.
Crypted file systems only make sense on machines, where definetely sensitive local user data is stored. If a machine is generally used by many people at school, then the crypto file system must be sealed by TPM. Machines that are "owned" by one or a few persons at school, could also be encrypted via passphrases. Up-to-now, we don't have crypto filesytem support in Debian Edu's installation procedure.
Now, one can argue... The systems are hackable anyway, so why bother with securing LDAP cert deployment? But that's the wrong thread of reasoning. We should rather consider adding grub passphrase protection and crypto filesystem (where demanded) support into the installer somehow. (I'd volunteer for the GRUB passphrase stuff).
Greets, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Attachment:
pgpTQQKKn1kk2.pgp
Description: Digitale PGP-Signatur