Default Filesystem Integrity checker

* Current Status:

* Samhain:
 * In universe (dapper 2.0.10a, hardy+ 2.2.3)
 * Upstream is at 2.5.5 (active development), 2.2.3 is from 31 july 2006
 * Checks POSIX ACLs and SELinux attributes
 * Centralized policy support not compiled in by default (network information needs to be compiled in)
 * Can check kernel modifications/rootkits, but not compiled in by default (needs /dev/kmem, so probably no longer works)
 * Can log to prelude ids
 * Supports pgp-signed config files, but not compiled in by default (key needs to be specified at compile time)
 * Notifications: email, syslog, console, logfile, log server, external, sqldb, prelude
 * Web-based console (proprietary)

* Tripwire:
 * In universe (dapper to karmic have 2.3.1.2.0)
 * Upstream is at 2.4.1.2 (released 18 april 2007)
 * Doesn't seem to have any active development
 * Forked from proprietary product in 1999, separate development now

* Aide:
 * In main (dapper has 0.10, hardy+ have 0.13.1)
 * Upstream is at 0.13.1 (released 15 dec 2006)
 * Doesn't seem to have any active development
 * Supports database and config file signing (but not enabled by default, key needs to be specified at compile time)

* Problems
 * not much upstream development (excepting samhain)
 * All have few CVEs, and are rather old (in general)
 * difficult to maintain due to frequency of security updates. people turn it off
 * (aide) can't easily incrementally update files

* Questions:
 * Should Aide stay in main? YES (no clear advantage to switch)
 * Should samhain be promoted to main? NO (no clear advantage to make change)
 * Is distributing Samhain as a binary useless?

* What features are we looking for?
 * IMORTANT: Gracefully handling OS package/security updates
 * Usable binaries? (ie: no compile-time options)
 * network database (stores hashes and can report)
 * network reporting (when clients have problems, report it)
 * could just check hashes, like debsums

* Package integration
 * Possible implementation for upgrades
  # detect changed files before the update
  # upgrade
  # rebuild database
  # report the changed files from before the upgrade and the files after the upgrade (ie, have a short list and a long list)
  # prompt to upgrade database (or give option to ignore the security ones)
 * must be opt-in
 * drawbacks
   * window between detection of changed and upgrade
   * other issues should be the same as for a default installation (eg, read-write database, not centrally managed, binary could be modified, etc, etc)
   * can lose data if the binary that changed is overwritten by the upgrade
 * to work around this, can simply abort an upgrade if there are uncommitted changes. perhaps an option?

* Documentation
 * using aide
 * concepts on fully protecting (ie read-only media, static binary, etc, etc)