Bug#993935: debian-edu-ltsp-install: Netboot image exposes private data and crypto keys
Package: debian-edu-config
Version: 2.11.56
Severity: critical
Tags: security
Justification: root security hole
X-Debbugs-Cc: Debian Security Team <team@security.debian.org>
The LTSP netboot image produced by debian-edu-ltsp-install includes full copies
of files that should never leave the Debian Edu main server, if run on a so-called
"combined server" (a system using the Main Server and Terminal Server profiles,
as done in small installations).
Among these files are full copies of, among others:
- /var/lib/ldap, containing the full, unencrypted LDAP database with all
private information on all users, password hashes, and Kerberos keys
- /etc/krb5-kdc, containing information on decrypting Kerberos data in the
LDAP database
- /etc/gosa, containing the (encrypted) LDAP manager credentials, plus the
key to decrypt it
Any user with access to the local terminal server network can acquire the netboot
image, unauthenticated, and extract the listed information from it.
The issue is caused by the new LTSP system using the LTSP PnP system now in all
cases, thus packing the entire mai nserver filesystem in squashfs image. The
debian-edu-ltsp-install script produces a list of files to exclude from the image,
which is not sufficient, most probably because it was tailored to the use case where
the image is produced from a dedicated Terminal Server instead of a combined server.
IMHO, the use case of the combined server cannot be fixed. The new LTSP system de facto
disallows any use of a combiend server – even if we make a very carefully curated list
of excluded files, any administrator would have to take care to add their own excludes
for just about any file they place on the main server that was not palced there by the
Debian Edu software. In fact, the whole new LTSP system seems unfit to be used on any
server that is not limited to producing LTSP images, and supporting netbooting them.
For now, the issue should be mitigated by carefully adding all relevant paths that
are known to exist only on the main server to the exclude list, but I do not think
that is a viable fix in the long term.
Reply to: