Differences between revisions 8 and 9
Revision 8 as of 2006-11-07 18:13:04
Size: 3837
Editor: vpn-nat
Comment: more stuff
Revision 9 as of 2006-11-07 18:15:13
Size: 2963
Editor: vpn-nat
Comment: clean up ideas that did move in the spec or rejected
Deletions are marked like this. Additions are marked like this.
Line 54: Line 54:
 * An integrity check with {{{
   for I in /var/lib/dpkg/info/*.md5sums; do
     [ $I != "/var/lib/dpkg/info/udev.md5sums" ] && md5sum -c $I;
   done | awk '! /OK$/ { print; }'
}}} gives quite reasonable results. On a server installation (no gui) only `/usr/bin/perldoc` was a false positive, which is autogenerated.

 * If we can check the integrity of the md5sums, we have what we need. Maybe we can put a checksum of the md5sums file of each package in a new field in the `_Packages` file? The integrity of the `_Packages` files is in turn verified by apt and a gpg key.

 ** There is very little point to add this check when the md5 on the system cannot be trusted. The whole point of having pkgsum.u.c (that is already working) is to use a trusted external source. The more data you need to trust from the compromised machine, the worst result you get.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This is a leftover from Dapper server spec.


A lot of sysadmins have the need to do lightweight intrusion detection to ensure system integrity. system-integrity-check provides a way to at least verify a big set of data on an installed system to ensure that main set of tools have not been compromised. The checker is *NOT* a replacement for a full intrusion detection system.

Use cases

  • Elmo wants to verify that all the binaries on a certain system are still ok. He knows that system-integrity-check can do that offline using a trusted source of data ( Once verified that the main set of binaries are still intact, he will be able to reinstall whatever is corrupted or compromised with very little effort due to the detailed report that's generated by the scan. He is also aware that not everything can be checked, but at least the system is safe enough to be accessible.


  • Infrastructure at the datacenter ( is now available and updated automatically.
  • move to use https (high priority):
    • change
    • adapt the client to use https (wget in the installer comes from busybox and verification for ssl supports need to be performed).
  • system-integrity-check code is in the archive and hooked up to rescue d-i boot option (done).
  • move system-integrity-check to main and make it part of cd images.
  • add more checks to system-integrity-check:
    • check for orphaned files.
    • add SHA1 checks (does it add anything compared to md5)?
    • attempt to not rely on dpkg database on the installed system.
  • offer the code as deb to run on the running system (low priority due to the hooks with d-i).
  • in the long term, get soyuz to populate pkgsum (separate spec in progress with malcc).
  • add option to "add external pkgsum archive" for internal company use that do not want to use pkgsum or add pkgs to the archive.
  • add concept of Origin: on server (need to provide) and client (need to understand) to support mixed archives from pkgsum and custom repositories.

Unresolved issues

  • Abstracting the tool from the dpkg db on the installed system is not trivial and might end up in tons of false positive. is it actually worth doing it? also in front of the fact that the system will need a reinstall if such db is compromised.
  • find a more fancy name (cockfosters?)


BoF agenda and discussion


IntegrityCheck (last edited 2008-08-06 16:14:39 by localhost)