-
As reported earlier, the last few days I have looked at how Debian
-Edu clients are configured, and tried to get rid of all hardcoded
-configuration settings on the clients. I believe the work to be
-mostly done, and the clients seem to work just fine with dynamically
-generated configuration.
-
-
What is the point, you might ask? The point is to allow a Debian
-Edu desktop to integrate into an existing network infrastructure
-without any manual configuration.
-
-
This is what happens when installing a Debian Edu client here at
-the University of Oslo using PXE. With the PXE installation, I am
-asked for language (Norwegian Bokmål), locality (Norway) and keyboard
-layout (no-latin1), Debian Edu profile (Roaming Workstation), if I
-accept to reformat the hard drive (yes), if I want to submit info to
-popcon.debian.org (no) and root password (secret). After answering
-these questions, the installer goes ahead and does its thing, and
-after around 50 minutes it is done. I press enter to finish the
-installation, and the machine reboots into KDE. When the machine is
-ready and kdm asks for login information, I enter my university
-username and password, am told by kdm that a local home directory has
-been created and that I must log in again, and finally log in with the
-same username and password to the KDE 4.4 desktop. At no point during
-this process did it ask for university specific settings, and all the
-required configuration was dynamically detected using information
-fetched via DHCP and DNS. The roaming workstation is now ready for
-use.
-
-
How was this done, you might wonder? First of all, here is the
-list of things that need to be configured on the client to get it
-working properly out of the box:
-
-
-- IP address/netmask and DNS server.
-- Web proxy URL.
-- LDAP server for NSS directory information (user, group, etc).
-- Kerberos server for PAM password checking.
-- SMB mount point to access the network home directory. (*)
-- Central syslog server to send syslog messages to. (*)
-- Sitesummary collector URL to submit info to central server. (*)
-
-
-
(Hm, did I forget anything? Let me knew if I did.)
-
-
The points marked (*) are not required to be able to use the
-machine, but needed to provide central storage and allowing system
-administrators to track their machines. Since yesterday, everything
-but the sitesummary collector URL is dynamically discovered at boot
-and installation time in the svn version of Debian Edu.
-
-
The IP and DNS setup is fetched during boot using DHCP as usual.
-When a DHCP update arrives, the proxy setup is updated by looking for
-http://wpat/wpad.dat and using the content of this WPAD file to
-configure the http and ftp proxy in /etc/environment and
-/etc/apt/apt.conf. I decided to update the proxy setup using a DHCP
-hook to ensure that the client stops using the Debian Edu proxy when
-it is moved outside the Debian Edu network, and instead uses any local
-proxy present on the new network when it moves around.
-
-
The DNS names of the LDAP, Kerberos and syslog server and related
-configuration are generated using DNS information at boot. First the
-installer looks for a host named ldap in the current DNS domain. If
-not found, it looks for _ldap._tcp SRV records in DNS instead. If an
-LDAP server is found, its root DSE entry is requested and the
-attributes namingContexts and defaultNamingContext are used to
-determine which LDAP base to use for NSS. If there are several
-namingContexts attibutes and the defaultNamingContext is present, that
-LDAP subtree is used as the base. If defaultNamingContext is missing,
-the subtrees listed as namingContexts are searched in sequence for any
-object with class posixAccount or posixGroup, and the first one with
-such an object is used as the LDAP base. For Kerberos, a similar
-search is done by first looking for a host named kerberos, and then
-for the _kerberos._tcp SRV record. I've been unable to find a way to
-look up the Kerberos realm, so for this the upper case string of the
-current DNS domain is used.
-
-
For the syslog server, the hosts syslog and loghost are searched
-for, and the _syslog._udp SRV record is consulted if no such host is
-found. This algorithm works for both Debian Edu and the University of
-Oslo. A similar strategy would work for locating the sitesummary
-server, but have not been implemented yet. I decided to fetch and
-save these settings during installation, to make sure moving to a
-different network does not change the set of users being allowed to
-log in nor the passwords required to log in. Usernames and passwords
-will be cached by sssd when the user logs in on the Debian Edu
-network, and will not change as the laptop move around. For a
-non-roaming machine, there is no caching, but given that it is
-supposed to stay in place it should not matter much. Perhaps we
-should switch those to use sssd too?
-
-
The user's SMB mount point for the network home directory is
-located when the user logs in for the first time. The LDAP server is
-consulted to look for the user's LDAP object and the sambaHomePath
-attribute is used if found. If it isn't found, the home directory
-path fetched from NSS is used instead. Assuming the path is of the
-form /site/server/directory/username, the second part is looked up in
-DNS and used to generate a SMB URL of the form
-smb://server.domain/username. This algorithm works for both Debian
-edu and the University of Oslo. Perhaps there are better attributes
-to use or a better algorithm that works for more sites, but this will
-do for now. :)
-
-
This work should make it easier to integrate the Debian Edu clients
-into any LDAP/Kerberos infrastructure, and make the current setup even
-more flexible than before. I suspect it will also work for thin
-client servers, allowing one to easily set up LTSP and hook it into a
-existing network infrastructure, but I have not had time to test this
-yet.
-
-
If you want to help out with implementing these things for Debian
-Edu, please contact us on debian-edu@lists.debian.org.
-
-
Update 2010-08-09: Simon Farnsworth gave me a heads-up on how to
-detect Kerberos realm from DNS, by looking for _kerberos TXT entries
-before falling back to the upper case DNS domain name. Will have to
-implement it for Debian Edu. :)
+
The last few days I have looked at ways to track open security
+issues here at my work with the University of Oslo. My idea is that
+it should be possible to use the information about security issues
+available on the Internet, and check our locally
+maintained/distributed software against this information. It should
+allow us to verify that no known security issues are forgotten. The
+CVE database listing vulnerabilities seem like a great central point,
+and by using the package lists from Debian mapped to CVEs provided by
+the testing security team, I believed it should be possible to figure
+out which security holes were present in our free software
+collection.
+
+
After reading up on the topic, it became obvious that the first
+building block is to be able to name software packages in a unique and
+consistent way across data sources. I considered several ways to do
+this, for example coming up with my own naming scheme like using URLs
+to project home pages or URLs to the Freshmeat entries, or using some
+existing naming scheme. And it seem like I am not the first one to
+come across this problem, as MITRE already proposed and implemented a
+solution. Enter the Common
+Platform Enumeration dictionary, a vocabulary for referring to
+software, hardware and other platform components. The CPE ids are
+mapped to CVEs in the National
+Vulnerability Database, allowing me to look up know security
+issues for any CPE name. With this in place, all I need to do is to
+locate the CPE id for the software packages we use at the university.
+This is fairly trivial (I google for 'cve cpe $package' and check the
+NVD entry if a CVE for the package exist).
+
+
To give you an example. The GNU gzip source package have the CPE
+name cpe:/a:gnu:gzip. If the old version 1.3.3 was the package to
+check out, one could look up
+cpe:/a:gnu:gzip:1.3.3
+in NVD and get a list of 6 security holes with public CVE entries.
+The most recent one is
+CVE-2010-0001,
+and at the bottom of the NVD page for this vulnerability the complete
+list of affected versions is provided.
+
+
The NVD database of CVEs is also available as a XML dump, allowing
+for offline processing of issues. Using this dump, I've written a
+small script taking a list of CPEs as input and list all CVEs
+affecting the packages represented by these CPEs. One give it CPEs
+with version numbers as specified above and get a list of open
+security issues out.
+
+
Of course for this approach to be useful, the quality of the NVD
+information need to be high. For that to happen, I believe as many as
+possible need to use and contribute to the NVD database. I notice
+RHEL is providing
+a
+map from CVE to CPE, indicating that they are using the CPE
+information. I'm not aware of Debian and Ubuntu doing the same.
+
+
To get an idea about the quality for free software, I spent some
+time making it possible to compare the CVE database from Debian with
+the CVE database in NVD. The result look fairly good, but there are
+some inconsistencies in NVD (same software package having several
+CPEs), and some inaccuracies (NVD not mentioning buggy packages that
+Debian believe are affected by a CVE). Hope to find time to improve
+the quality of NVD, but that require being able to get in touch with
+someone maintaining it. So far my three emails with questions and
+corrections have not seen any reply, but I hope contact can be
+established soon.
+
+
An interesting application for CPEs is cross platform package
+mapping. It would be useful to know which packages in for example
+RHEL, OpenSuSe and Mandriva are missing from Debian and Ubuntu, and
+this would be trivial if all linux distributions provided CPE entries
+for their packages.