1TWPOLICY(4) Kernel Interfaces Manual TWPOLICY(4)
2
6 twpolicy - Tripwire policy file reference
7
9 The policy file describes system objects to be monitored by Tripwire,
10 and specifies what properties for each object should be collected and
11 stored in the database file. Each object in the policy file is associ‐
12 ated with a property mask, which describes what changes to the file or
13 directory Tripwire should monitor, and which ones can safely be
14 ignored. By customizing the various aspects of the policy file, the
15 system administrator can very closely control how Tripwire checks the
16 integrity of any system.
17 During installation, an encoded and signed policy file (tw.pol) will be
19 created in the /etc/tripwire directory, and a plain text copy of this
20 policy file (twpol.txt) will be generated in the same directory. An
21 additional text file (policyguide.txt) illustrates all of the features
22 of the policy language. Both of the text files are heavily commented
23 and can be used as a reference during policy file creation.
24 A new policy file is first created using the twadmin ‐‐create‐polfile
26 command. With this command, the user can designate an existing plain
27 text file as the current policy file. Using the current site key and
28 passphrase, the new configuration file is encoded, signed and saved.
29 Once the initial policy file has been generated, any changes should be
31 made with the tripwire ‐‐update‐policy command, rather than by simply
32 overwriting the policy file with the twadmin ‐‐create‐polfile command.
33 This is an important distinction‐‐when a new policy file is created,
34 the Tripwire database must be re-initialized. If an intruder has modi‐
35 fied files since the last integrity check, these changes will not be
36 detected, and will be included as part of the new "baseline" database.
37
39 The basic components of policy files are comments, rules, directives,
40 and variables. Each of these components is described in greater detail
41 below.
42 Comments
44 In a policy file, any text following a '#', up to the next line break,
45 is considered a comment. Example:
46 # This is a comment.
48 /bin -> $(ReadOnly); # A comment can go here, too.
49 Rules
51 Policy rules determine whether and to what extent Tripwire will check
52 particular files and directories. There are two kinds of policy rules
53 recognized by Tripwire:
54 1) Normal rules define which properties of a particular file or direc‐
56 tory tree Tripwire scans.
57 2) Stop points tell Tripwire not to scan a particular file or direc‐
58 tory.
59 Normal Rules
61 The format for a normal rule is:
62 object_name -> property_mask;
63 where the object_name is the fully qualified pathname for a directory
65 or file, and property_mask specifies what properties of an object to
66 examine or ignore. The '‐>' token separates the pathname and the prop‐
67 erty mask. Whitespace must separate the object name and '‐>' token. A
68 semicolon must terminate the rule. If the pathname specified is a
69 directory, the directory and all of its descendants will be scanned
70 with the indicated property mask. If the pathname refers to an indi‐
71 vidual file, only that file will be scanned with the specified property
72 mask. Examples:
73 # Defines Tripwire behavior for entire /bin directory tree.
75 /bin -> $(ReadOnly);
76 # Defines Tripwire behavior for a single file. In this case,
78 # Tripwire watches for all properties of hostname.hme0.
79 /etc/hostname.hme0 -> $(IgnoreNone) -ar;
80 # Scan the entire /etc directory tree using mask1, except the
82 # file /etc/passwd, which should be scanned using mask2.
83 /etc -> $(mask1);
84 /etc/passwd -> $(mask2);
85 Only one rule may be associated with any given object. If any object
87 has more than one rule in a policy file, Tripwire will print an error
88 message and exit without scanning any files. For example:
89 # This is an example of an illegal construct.
91 /usr/bin -> $(mask3);
92 /usr/bin -> $(mask4);
93 Object Names
95 In this document, policy file objects are fully qualified pathnames of
96 files and directories. Environment variables are not allowed for secu‐
97 rity reasons. Examples:
98 /etc # valid object name.
100 /etc/passwd # valid object name.
101 $HOME # not valid.
102 Property Masks
104 Property masks designate which Tripwire properties of a given object
105 should be examined. A property mask consists of a series of single-
106 character symbols, each of which may be preceded by an optional plus or
107 minus sign. Each character symbol stands for a particular Tripwire
108 property to be examined during integrity checking. If the character is
109 preceded by a plus, checking is done for that property; if preceded by
110 a minus, checking is not done for that property. For example:
111 +p # compare permissions.
113 -p # ignore permissions.
114 Each rule in the policy file must have a property mask. Examples:
116 /etc -> $(IgnoreAll); #valid property mask.
118 /etc -> +p-p; #valid property mask.
119 /etc -> ; #invalid property mask.
120 Characters in a property mask without a preceding plus or minus sign
122 are assumed to be plus. If a property is not specified in the property
123 mask, it is ignored, which is equivalent to turning it off with the
124 minus sign. Examples:
125 # Examine permissions and link count.
127 # All three of the following are equivalent.
128 +p+n
129 pn
130 pn-g
131 Characters used in property masks, with descriptions:
133 - Ignore the following properties
135 + Record and check the following properties
136 a Access timestamp
137 b Number of blocks allocated
138 c Inode timestamp (create/modify)
139 d ID of device on which inode resides
140 g File owner's group ID
141 i Inode number
142 l File is increasing in size (a "growing file")
143 m Modification timestamp
144 n Number of links (inode reference count)
145 p Permissions and file mode bits
146 r ID of device pointed to by inode
147 (valid only for device objects)
148 s File size
149 t File type
150 u File owner's user ID
151 C CRC-32 hash value
152 H Haval hash value
153 M MD5 hash value
154 S SHA hash value
155 Stop Points
157 Stop points are used to specify specific files or directories that
158 Tripwire should not scan. The syntax for stop points is:
159 ! object_name ;
160 For example:
161 !/etc/init.d;
162 # The directory /etc/init.d will not be scanned.
163 /etc -> $(ReadOnly);
165 !/etc/rc.d;
166 !/etc/mnttab;
167 # Scan all of /etc, but do not scan two particular
168 # files in the /etc hierarchy.
169 Rule Attributes
171 Rule attributes work with normal rules to modify their behavior or pro‐
172 vide additional information. Multiple attributes can be assigned to
173 each rule. Rule attributes are not case-sensitive. Rule attributes
174 may be applied to a single rule using the following syntax:
175 object_name -> property_mask (rule attribute = value);
176 For example:
177 /usr/lib -> $(ReadOnly) (emailto = admin@foo.com, severity = 80);
178 #This rule will notify the admin if any violations of the
179 #rule occur and designate the severity as 80.
180 Rule attributes can also be specified for a group of rules, using the
182 format:
183 (attribute list)
184 {
185 rule list;
186 }
187 For example:
188 (emailto = admin@foo.com, severity = 80)
189 {
190 /usr/lib -> $(ReadOnly);
191 }
192 is equivalent to the attribute example above.
193 The following four rule attributes are supported by Tripwire:
195 rulename The rulename attribute is used to associate a rule or
197 set of rules with a specific name. In a report file,
198 this name will be associated with violations to the
199 specified rule. This feature is useful if you want to
200 track certain objects within a large Tripwire database.
201 For instance, if you associate the rule name "watchme"
202 with important files, you can sort through the Tripwire
203 report using "watchme" as a sorting key.
204 Example:
205 /etc -> +ug (rulename=watchme);
206 emailto The emailto attribute associates one or more email
208 addresses with a rule or group of rules. When an
209 integrity check is run with the ‐‐email‐report option
210 and a rule is violated, a report of that violation will
211 be sent to the specified email address(es), using the
212 report format specified by the EMAILREPORTLEVEL variable
213 in the configuration file.
214 Example:
215 /etc -> +ug (emailto=admin@domain.com);
216 To specify multiple email addresses, include them as a
218 quoted, semicolon-delimited list.
219 /etc -> +ug (emailto="admin@foo.com;admin2@foo.com");
220 severity The severity attribute associates a numeric severity
222 level with a rule. When Tripwire is run in Integrity
223 Checking mode, it is possible to specify that only rules
224 exceeding a certain severity level are used. The
225 default severity level is 0, and values can range from 0
226 to 1,000,000.
227 Example:
228 /etc -> +ug (severity=50);
229 recurse The recurse attribute specifies how a rule will scan
231 directories. Valid values for recurse are true, false,
232 or a number from -1 to 1,000,000. If recurse is set to
233 true (or ‐1), tripwire will recursively scan the entire
234 contents of the directory (both files and subdirecto‐
235 ries). When recurse is set to false (or 0), and the rule
236 refers to a directory, Tripwire will scan the inode of
237 the directory but none of the files or subdirectories
238 contained therein. For positive recurse value n, the
239 rule will monitor all objects up to n levels below the
240 start point. Stop points within the recursed directory
241 still apply, and will prevent the specified file or
242 directory from being scanned.
243 When a rule refers to a file, specifying the recurse
245 attribute has no effect‐‐files will be scanned no matter
246 what value is given for recurse. The default value for
247 recurse is true.
248 Example:
249 /etc -> +ug (recurse=2);
250 Directives
252 Tripwire supports a small number of directives that allow conditional
253 interpretation of the policy file and certain diagnostic and debugging
254 operations. The primary purpose of directives is to support sharing of
255 a policy file among multiple machines. Directives use the following
256 syntax:
257 @@ directive_name [arguments]
258 Where the directive name is one of the directives listed below:
260 @@section # Designates a section of the policy file.
262 @@ifhost # Allow conditional interpretation
264 @@else # of the policy file.
265 @@endif
266 @@print # Print a message to standard output.
268 @@error # Print a message to standard output and then exit.
269 @@end # Marks the logical end-of-file.
271 The @@section directive is used to designate sections of the policy
273 file that are OS-specific. With Tripwire 2.4, valid arguments for the
274 @@section directive are FS and GLOBAL. If no @@section directive is
275 specified, FS will be assumed. If the argument to the @@section direc‐
276 tive is either NTFS or NTREG (which have meaning only on Windows NT
277 systems), Tripwire will skip all policy file text down to the next
278 valid @@section directive. Any other argument will cause an error.
279 The @@ifhost, @@else, and @@endif directives are used to allow condi‐
281 tional interpretation of the policy file. With the @@ifhost directive,
282 multiple hostnames can be expressed as arguments, but they must be sep‐
283 arated by an '||', interpreted as the logical 'OR'. This example
284 illustrates how one might employ directives to use one policy file with
285 multiple hosts.
286 @@ifhost spock || kirk
288 /bin -> $(ReadOnly);
289 @@endif
290 @@ifhost chekov || uhura
292 /usr/bin -> +pinug;
293 @@else
294 /usr/bin -> +pinugsmC;
295 @@endif
296 The @@print and @@error directives are intended for debugging and
298 remote diagnostics. The syntax for these commands is:
299 @@print "string"
300 @@error "string"
301 The @@print directive prints string to stdout, while the @@error direc‐
303 tive prints string to stdout and causes the calling program to exit
304 with a non-zero status.
305 The @@end directive marks the end of the policy file. Any text appear‐
307 ing after this directive will be ignored by Tripwire.
308 Variables
310 For user convenience, Tripwire's policy file supports variables for
311 string substitution. Variables can be defined anywhere between rules.
312 The syntax for variable definition is:
313 variable = value;
314 Variable substitution is legal anywhere that a string could appear.
316 The syntax for variable substitution is:
317 $( variable )
318 Examples of variable definition and variable substitution on the left,
320 right, and both sides of rules. Note that variable names are case sen‐
321 sitive.
322 param1 = +SMCH; # Set variable param1.
324 dir1 = /etc/inet; # Set variable dir1.
325 DIR1 = /etc/init.d; # Variables are case sensitive.
326 $(dir1) -> +tbamc; # Left hand substitution.
327 /etc/inet -> $(param1); # Right hand substitution.
328 $(DIR1) -> $(param1); # Double substitution.
329 A number of variables are predefined by Tripwire and may not be
331 changed. These variables represent different ways that files can
332 change, and can be used on the right side of rules to design a policy
333 file quickly.
334 ReadOnly ReadOnly is good for files that are widely available but
336 are intended to be read-only.
337 Value: +pinugtsdbmCM‐rlacSH
338 Dynamic Dynamic is good for monitoring user directories and
340 files that tend to be dynamic in behavior.
341 Value: +pinugtd‐srlbamcCMSH
342 Growing The Growing variable is intended for files that should
344 only get larger.
345 Value: +pinugtdl‐srbamcCMSH
346 Device Device is good for devices or other files that Tripwire
348 should not attempt to open.
349 Value: +pugsdr‐intlbamcCMSH
350 IgnoreAll IgnoreAll tracks a file's presence or absence, but
352 doesn't check any other properties.
353 Value: ‐pinugtsdrlbamcCMSH
354 IgnoreNone IgnoreNone turns on all properties and provides a conve‐
356 nient starting point for defining your own property
357 masks. (For example, mymask = $(IgnoreNone) -ar;)
358 Value: +pinugtsdrbamcCMSH‐l
359
361 This man page describes Tripwire 2.4.
362
364 Tripwire, Inc.
365
367 Permission is granted to make and distribute verbatim copies of this
368 man page provided the copyright notice and this permission notice are
369 preserved on all copies.
370 Permission is granted to copy and distribute modified versions of this
372 man page under the conditions for verbatim copying, provided that the
373 entire resulting derived work is distributed under the terms of a per‐
374 mission notice identical to this one.
375 Permission is granted to copy and distribute translations of this man
377 page into another language, under the above conditions for modified
378 versions, except that this permission notice may be stated in a trans‐
379 lation approved by Tripwire, Inc.
380 Copyright 2000-2018 Tripwire, Inc. Tripwire is a registered trademark
382 of Tripwire, Inc. in the United States and other countries. All rights
383 reserved.
384
386 twintro(8), tripwire(8), twadmin(8), twprint(8), siggen(8), twcon‐
387 fig(4), twfiles(5)
388Open Source Tripwire 2.4 04 Jan 2018 TWPOLICY(4)