------------------------------------------------------------------------------ Open Source Tripwire 2.3.1, build 2 for Linux Release Notes March 3, 2001 ------------------------------------------------------------------------------ CONTENTS: - Introduction - Where to look for help - Contacting Tripwire - The Tripwire Policy file - Known issues - Differences from Tripwire ASR 1.3 Introduction ------------------------------------------------------------------------------ Welcome to Open Source Tripwire 2.3.1 for Linux. This document contains up-to-the-minute information on the known issues and behaviors of this release of Tripwire. Please read this document carefully before installing Tripwire or reporting any bugs. We have also included contact information for your benefit. Please tell us about any bugs you find and also how you feel about our product. Where to look for help ------------------------------------------------------------------------------ We recommended that you refer to the README file and policyguide.txt file, for helpful information. The Open Source Tripwire home page also contains information about this version of Tripwire, and other resources. Visit this web site at http://www.tripwire.org. Contacting Tripwire ------------------------------------------------------------------------------ If you wish to contact Tripwire, Inc. to report bugs or make feature suggestions, reach us through one of the following: email:...............opensource@tripwire.org main site:...........http://www.tripwire.org development site:....http://sourceforge.net/project/?group_id=3130 The Tripwire Policy file: ------------------------------------------------------------------------------ An example Tripwire Policy file is included with this distribution. This example policy file, plus the Policy Guide provides enough information to help you customize a Tripwire Policy file for your own system. Start with tht example policy file to craete your own custom Tripwire Policy file. The text version of the Tripwire Policy file is named twpol.txt Note: The Tripwire Policy is tuned to an 'everything' install of RedHat Linux 7.0. If run unmodified, this file should not generate errors on database creation, or violations on subsequent integrity checks. However, it is impossible to provide one policy file for all machines. This example policy file is written to err on the side of security. Your Linux configuration will most likely differ from the one our policy file was tuned to. Therefore you may need to edit the example Tripwire Policy file. The example policy file is best run with 'Loose Directory Checking' enabled. Set LOOSEDIRECTORYCHECKING=TRUE in the Tripwire Configuration file. Known Issues ------------------------------------------------------------------------------ - Open Source Tripwire 2.3.1 has been tested on Linux Kernel 2.2.14 or higher. - Open Source Tripwire 2.3.1 has been build-tested using GCC 2.95.2 or higher and Glibc 2.1 or higher. - Source and Binary RPMs (if provided) require RPM version 3.0 or higher - Making modifications to an existing policy file requires the use of the --update-policy mode of Tripwire. This mode ensures that the database on disk is internally consistent with the policy file. Otherwise, ensuring that no changes have been made to the filesystem between the last integrity check and the policy file modification requires several steps. These steps include disconnecting the machine from the network, running an integrity check, updating the policy file and reinitializing the database. This update policy mode allows the same functionality and security of all these in one step. See the Tripwire section of the Command Reference in the User Manual for further information. - Using 'twadmin --create-polfile' to update an existing policy file causes errors on the next integrity check if the database is not regenerated from scratch. Errors are generated by rules added or modified from the policy file used to create the database. However, rules that are removed from the policy file generate no errors or warnings. Therefore, using '--secure-mode high' on an integrity check command line does not catch this inconsistency. It is STRONGLY recommended that you use 'tripwire --update-policy' to keep the Tripwire database and policy file in sync. See the Tripwire section of the Command Reference in the User Manual for further information. - The CLOBBER setting in install.cfg applies to everything except configuration and policy files. These files, if present, are always backed up and recreated to avoid the potential of leaving Tripwire in a state where it cannot run. If you have installed Tripwire over an existing installation, and wish to keep your old policy and configuration files, they can be recovered. Use the twadmin command to print the old configuration and policy files (tw.cfg.bak and tw.pol.bak) as text files and then re-encrypt them with the Tripwire 2.3.1 site key. - Specifying a rule that includes both a hash attribute (C, M, S, or H) AND the access timestamp attribute (a) is not recommended. This causes every file that was scanned using the rule to show up as having changed between scans. This is because Tripwire currently does not reset the access time attribute after it accesses the file to obtain a hash value. Thus the next scan shows every hashed file as having been accessed (by Tripwire). - Specifying a rule that monitors the access timestamp (a) causes every directory recursed while scanning that rule to show up as having changed between scans. This is because Tripwire does not reset the access time attribute after enumerating the directory contents. To avoid this, change the LOOSEDIRECTORYCHECKING value in the Tripwire configuration file to true. There are potential security implications for doing this, however [see the Configuration Reference section of the User Manual for more information]. - In the event that the umask is set such that files are created non-writeable by default, the editor launched in interactive integrity check and database update modes may be unable to save changes made to the report. If the editor is closed without saving the changes, Tripwire assumes that all items in the report should be updated, potentially including compromised data in the database. To exploit this vulnerability, an intruder would require a previously-compromised account with write access to either the Tripwire administrator's account or the Tripwire binaries. To work around this issue, launch a shell from the editor (":shell" in vi), add user-write (chmod u+w <filename>) permissions to the temp file open in the editor, exit the shell and force a write to the file (":w!" in vi). To avoid this issue, make certain that the umask does not contain the user-write bit (0200). - CAUTION: Tripwire keyfiles are inextricably linked to their associated signed files. Consequently, if you create a new keyfile and overwrite the pre-existing keyfile, all files signed with the original key become unusable. - When a folder or registry key is specified on the command line during a Tripwire integrity check, Tripwire *only* scans the specified object. It is not recursed. To scan and recurse through a specified object, that object must be a start point for a rule, and may be specified on the command line with the '--rule-name' parameter. - When specifying filenames in the policy file, the inclusion of multiple adjacent path delimiters in the filename may result in Tripwire being unable to locate or examine the file. To avoid this issue, ensure that paths are specified using standard naming conventions, and that variables used as part of a path do not include a trailing or preceeding path delimiter if one already exists adjacent to the variable. - The default policy file contains a rule for verifying the integrity of critical Tripwire components. The database, which must be generated after the policy file, is included as a component to verify. Therefore the first integrity check run after a default installation reports a violation that describes the database as "added". This issue can be avoided by initializing the database twice after installation, or by creating a zero-length file with the same path and filename as the database before running Tripwire in database initialization mode. - Due to operating system limitations, Tripwire may be unable to scan files larger than 2 GB on some older the Linux platforms. A non-fatal error is generated by attempts to access such files. Tripwire will be unable to retrieve some properties of these files, but otherwise operation is normal. - If the site keyfile specified in the config file differs from the key used to create a report or database,twprint is unable to print either of these files. This is because twprint does not support the "-S" argument with the capacity to override the default site keyfile. Twprint uses this argument strictly for validation of the data in the config file. - Email reports containing high-ascii or multi-byte characters are now MIME encoded if either the SMTP or Sendmail email reporting methods are specified in the configuration file. - If a filename includes character 0x5C, the filesystem may fail to pass the filename to tripwire correctly, causing tripwire to falsely see the file as having been removed. If the filename is passed on the command line, Tripwire is able to correctly interpret the filename. Differences from Tripwire ASR 1.3 ------------------------------------------------------------------------------ Tripwire 2.3.1 is the latest open-source release of Tripwire software. It is a complete rewrite of the source code from the Academic Source Release (ASR) versions of Tripwire. Tripwire 2.3.1 is based on the commercial Tripwire 2.x codebase. Several significant enhancements to original features and functionality have been created, such as: - Run-time global Tripwire variables are now stored in a configuration file. This avoids reliance on some easily compromized environment variables. - Slight change in terminology: - Tripwire policy file replaces "tw.config". - Tripwire configuration file replaces compile-time options. - More integrity checking options: - E-mail reporting. - Running rules based on severity levels or name. - More secure file handling: - Cryptographically-signed configuration, policy, and database files. This eliminates the need for removable or read-only media to store these files, and allows for automated use. Note: These files are still susceptible to deletion and must be backed up. - Optionally-signed reports. - Addition of twadmin and twprint commands provide interface to Tripwire data files for handling updating, encryption management, and printing. - Greatly enhanced policy language. We recommend that ASR policy files be reviewed according to the new specifications and altered accordingly. ASR policies and rules will not function correctly under Tripwire 2.3.1 without modification. - All rules now have a set of attributes that can be associated with them. (For example, rule names, severity levels, e-mail reporting recipients, recursion behavior, etc.) - Generalized grammar to handle future object monitoring. - Tripwire 2.3.1 uses a different Base64 (RFC 2045) alphabet than Tripwire 1.3. As a result, signature values will appear to be different for the same file. For CRC32 hashes, Tripwire 2.3.1 fixes an error in the calculation of this value, and results will differ by their 'one's complement'. Tripwire 2.3.1 now returns the same CRC32 value as the cksum utility. However, all other hash values are actually identical, but expressed differently. Generating signatures with hexadecimal (siggen -h) output will show the identical values. - Tripwire is Year 2000 (Y2K) compliant. ============================================================================= Copyright 2000 Tripwire, Inc. Tripwire is a registered trademark of Tripwire, Inc. in the United States and other countries. All rights reserved. Linux is a registered trademark of Linus Torvalds. UNIX is a registered trademark of The Open Group. ============================================================================= Permission is granted to make and distribute verbatim copies of this document provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this document under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this document into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by Tripwire, Inc.