Motto: better than DEBIAN/md5sum
Status: early-draft (contributions are welcome)
A user may want to validate the integrity of a system. The only sensible way to do it is to use some appropriate tools (HIDS...).
Unfortunately, those tools are usually effective if they where installed prior to the date where a problem is noticed. This is because most host-based intrusion detection system detects changes to file system objects, by comparing them with pre-computed files checksums on the same host.
This proposal aims to distribute a formal description of binary package, that could be used by HIDS to identify pristine binaries, configuration files, files permissions... so the admin can focus on the remaining issues.
This proposal may have some side effect benefits:
- Backup may detect pristine files that don't need to be saved, because they are available online anyway.
- Use the formal description to create/remove the described objects (user, groups, dpkg-statoverrides...), by using helpers in preinst/postinst and prerm/postrm scripts
The proposal (draft)
very early draft, anything may change
The pkgdesc control file of a binary package contains some information that can be used to verify that such installed package is still pristine, like verifying files checksums. This file format is extensible, so future versions of this specification can describe more aspects of a package.
Tools relying on this file to verify the integrity of a system should always use those data in a conservative way. For instance, the current version of the specification doesn't describe POSIX ACLs but that may be implemented in later release, any ACL on the analyzed filesystem should be reported as a modification if the information about ACL are not present in a given pkgdesc file.
The file format conforms to Debian-Policy, ยง5.1 Syntax of control files. The file can only contain a single stanza, other stanzas must be ignored.
The fields in this file are:
Package: (mandatory)
Architecture: (mandatory)
Version: (mandatory)
description: (recommended)
Control-SHA256: (mandatory)
Content-SHA256: (mandatory)
Package
The name of the binary package.
Must have the same value as the binary package Name: field in the control file.
Rational: there is no trusted copy of the original control file.
Architecture
The name of the binary package.
Must have the same value as the binary package Architecture: field in the control file.
Rational: there is no trusted copy of the original control file.
Description
This fields contains the package description.
Must contain the first line of the field Description: in the the binary package's control file.
Rational: there is no trusted copy of the original control file.
Content-SHA256
This fields contains the SHA-256 checksum of all the files contained in the binary package (in the content.tar.gz part).
The value of this field contains the output of sha256sum, padded with on space (because it's a wrapped RFC-822 value). All lines must match the regular expression grep -E '^ [[:xdigit:]]{64}[ ]+\/.*'
Control-SHA256
TODO Similar to Content-SHA256 above, but for control files. Every control files should be listed, excepted pkgdesc
existing HIDS analyze
AIDE
The AIDE database stores various file attributes including: permissions, inode number, user, group, file size, mtime and ctime, atime, growing size, number of links and link name. AIDE also creates a cryptographic checksum or hash of each file using one or a combination of the following message digest algorithms: sha1, sha256, sha512, md5, rmd160, tiger (gost and whirlpool can be compiled in if mhash support is available). Additionaly, the extended attributes acl, xattr and selinux can be used when expliticly enabled during compile time.
- Each set of files can have different rules, that define what is compulsory (/var/log/btmp must be UMASK=117, but have variable size/checksum)
- "Allow new files (in directory)" flags (adding a new file in /usr/share/doc is fine, but /usr/lib/xorg/modules/drivers is not).
Tripwire
Once an initial database is generated, Tripwire will detect changes made to files from this point on. You *must* be certain that the system on which you generate the initial database is clean, however --- Tripwire cannot detect unauthorized modifications that have already been made. One way to do this would be to take the machine to single-user mode, reinstall all system binaries, and run Tripwire in initialization mode before returning to multi-user operation. This database must be moved someplace where it cannot be modified. Because data from Tripwire is only as trustworthy as its database, choose this with care. We recommend placing all the system databases on a read-only disk (you need to be able to change the disk to writable during initialization and updates, however), or exporting it via read-only NFS from a "secure-server." (This pathname is encoded in the signed, encrypted Tripwire configuration file, /etc/tripwire/tw.cfg'. Any time you change the pathname to the database repository, you must generate a Tripwire configuration file. This prevents a malicious intruder from spoofing Tripwire into giving a false "okay" message.)
- The database can be shared by multiple system.
Rules have a severity so that you can quickly scan through a report to find the most critical changes.
Features/Data that could be used by HIDS
HIDS could use our data to warn (or whitelist) changes.
Considerations / things to work-out
Transition, extensibility
The current DEBIAN/md5sums file can't be modified/enhanced without breaking existing tools that relies on it.
The DEBIAN/md5sums are preserved for backward compatibility (for now). A new control file is added to binary package, named DEBIAN/pkgdesc (see #filename).
Limitation of current md5sums
- File format does not allow future enhancement, without taking the risk of breaking existing tools.
Distribution
- See
Should the file be included in the binary .deb ? should it be
Files checksums
The checksum should be robust. If multiple checksum exist in the pkgdesc file, it is up to the system admin to decide the one are trustee
Files permission
Declaration should be easy for package maintainers (either capture, like dh_md5sums, or declare in a single place for postinst & pkgdesc)
- Declaration should be formated in a way that is easy to interpret (by humans and tools)
- Should be declared in a way that is compatible with ACL
Existing script review
Existing helpers:
dbconfig (dbc_generate_include_owner ; dbc_generate_include_perms) like acibase
Other needs...
Apply chmod on upgrade only dpkg --compare-versions "$2" lt 0.47 && chmod ..., like acpi-support, acpid
Issues:
Inconsistent scripts behaviour (id $user, getent passwd $user...)
- Not ensuring file ownership (afbackup)
- Home creation for system accounts
Signature / Trust
Should debian/pkgdesc files be signed individually? How? When? by Whom?
Should debian/pkgdesc files by signed indirectly, by including their checkums in repositories .Packages file?
- Should we setup a new repository for that purpose?
HIDS limitation
- fingerprint
A mentioned in aide manual, First you must create a database against which future checks are performed. This should be done immediately after the operating system and applications have been installed, before the machine is plugged into a network.
--> To enforce this behavior, one would have to re-deploy the system each-time a new security update is shipped.
File name
In this draft, we assume that the file is named debian/pkgdesc. This name may change if a better name arise.
See also