• 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:

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 paragraph, other paragraphs must be ignored.

The fields in this file are:

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.

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.)

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

Distribution

Should the file be included in the binary .deb ? should it be

Files checksums

Files permission

Existing script review

Existing helpers:

Other needs...

Issues:

Signature / Trust

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