## page was renamed from Proposals/PackageFootprint #language en ##~-[[DebianWiki/EditorGuide#translation|Translation(s)]]: none-~ ##---- {{{#!wiki yellow * __Motto:__ ''better than DEBIAN/md5sum'' * __Status:__ early-draft (contributions are welcome) }}} ## If your page gets really long, uncomment this Table of Contents ## <> A user may want to validate the integrity of a system. The only sensible way to do it is to use some appropriate tools (WikiPedia: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) === {{{{{#!wiki yellow '''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 [[http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Source|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|Package]]: (mandatory) * [[#architecture|Architecture]]: (mandatory) * [[#version|Version]]: (mandatory) * [[#description|description]]: (recommended) * [[#control-sha256|Control-SHA256]]: (mandatory) * [[#content-sha256|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 DebianMan: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 [[http://sourceforge.net/projects/aide|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: * DebianPkg: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 [[http://www.cs.tut.fi/~rammer/aide/manual.html|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. ## You can add other _helpful_ links here. == See also == * [[Proposals]] * [[Sha256sumsInPackages]] ---- ## If this page belongs to an existing Category, add it below. ## CategorySomething | CategoryAnother