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.
I had now time to look into this; here are my thoughts (and please
correct me if I'm wrong):
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).
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 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 ] &&
> - 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.
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.
Please check so that we can have a good solution that works in all use
cases.
Wolfgang
Attachment:
signature.asc
Description: PGP signature