1AUDIT.RULES:(7) System Administration Utilities AUDIT.RULES:(7)
2
6 audit.rules - a set of rules loaded in the kernel audit system
7
9 audit.rules is a file containing audit rules that will be loaded by the
10 audit daemon's init script whenever the daemon is started. The auditctl
11 program is used by the initscripts to perform this operation. The syn‐
12 tax for the rules is essentially the same as when typing in an auditctl
13 command at a shell prompt except you do not need to type the auditctl
14 command name since that is implied. The audit rules come in 3 vari‐
15 eties: control, file, and syscall.
16 Control
19 Control commands generally involve configuring the audit system rather
20 than telling it what to watch for. These commands typically include
21 deleting all rules, setting the size of the kernel's backlog queue,
22 setting the failure mode, setting the event rate limit, or to tell
23 auditctl to ignore syntax errors in the rules and continue loading.
24 Generally, these rules are at the top of the rules file.
25 File System
28 File System rules are sometimes called watches. These rules are used to
29 audit access to particular files or directories that you may be inter‐
30 ested in. If the path given in the rule is a directory, then the rule
31 used is recursive to the bottom of the directory tree excluding any
32 directories that may be mount points. The syntax of these rules gener‐
33 ally follow this format:
34 -w path-to-file -p permissions -k keyname
36 where the permission are any one of the following:
38 r - read of the file
41 w - write to the file
43 x - execute the file
45 a - change in the file's attribute
47 System Call
49 The system call rules are loaded into a matching engine that intercepts
50 each syscall that all programs on the system makes. Therefore it is
51 very important to only use syscall rules when you have to since these
52 affect performance. The more rules, the bigger the performance hit. You
53 can help the performance, though, by combining syscalls into one rule
54 whenever possible.
55 The Linux kernel has 4 rule matching lists or filters as they are some‐
57 times called. They are: task, exit, user, and exclude. The task list is
58 checked only during the fork or clone syscalls. It is rarely used in
59 practice.
60 The exit filter is the place where all syscall and file system audit
62 requests are evaluated.
63 The user filter is used to filter (remove) some events that originate
65 in user space. By default, any event originating in user space is
66 allowed. So, if there are some events that you do not want to see, then
67 this is a place where some can be removed. See auditctl(8) for fields
68 that are valid.
69 The exclude filter is used to exclude certain events from being emit‐
71 ted. The msgtype field is used to tell the kernel which message types
72 you do not want to record. This filter can remove the event as a whole
73 and is not selective about any other attribute. The user and exit fil‐
74 ters are better suited to selectively auditing events.
75 Syscall rules take the general form of:
77 -a action,list -S syscall -F field=value -k keyname
79 The -a option tells the kernel's rule matching engine that we want to
81 append a rule at the end of the rule list. But we need to specify which
82 rule list it goes on and what action to take when it triggers. Valid
83 actions are:
84 always - always create an event
87 never - never create an event
89 The action and list are separated by a comma but no space in between.
91 Valid lists are: task, exit, user, and exclude. Their meaning was
92 explained earlier.
93 Next in the rule would normally be the -S option. This field can either
95 be the syscall name or number. For readability, the name is almost
96 always used. You may give more than one syscall in a rule by specifying
97 another -S option. When sent into the kernel, all syscall fields are
98 put into a mask so that one compare can determine if the syscall is of
99 interest. So, adding multiple syscalls in one rule is very efficient.
100 When you specify a syscall name, auditctl will look up the name and get
101 its syscall number. This leads to some problems on bi-arch machines.
102 The 32 and 64 bit syscall numbers sometimes, but not always, line up.
103 So, to solve this problem, you would generally need to break the rule
104 into 2 with one specifying -F arch=b32 and the other specifying -F
105 arch=b64. This needs to go in front of the -S option so that auditctl
106 looks at the right lookup table when returning the number.
107 After the syscall is specified, you would normally have one or more -F
109 options that fine tune what to match against. Rather than list all the
110 valid field types here, the reader should look at the auditctl man page
111 which has a full listing of each field and what it means. But its worth
112 mentioning a couple things.
113 The audit system considers uids to be unsigned numbers. The audit sys‐
115 tem uses the number -1 to indicate that a loginuid is not set. This
116 means that when its printed out, it looks like 4294967295. If you write
117 a rule that you wanted try to get the valid users of the system, you
118 need to look in /etc/login.defs to see where user accounts start. For
119 example, if UID_MIN is 500, then you would also need to take into
120 account that the unsigned representation of -1 is higher than 500. So
121 you would address this with the following piece of a rule:
122 -F auid>=500 -F auid!=4294967295
124 These individual checks are "anded" and both have to be true.
126 The last thing to know about syscall rules is that you can add a key
128 field which is a free form text string that you want inserted into the
129 event to help identify its meaning. This is discussed in more detail in
130 the NOTES section.
131
134 The purpose of auditing is to be able to do an investigation periodi‐
135 cally or whenever an incident occurs. A few simple steps in planning up
136 front will make this job easier. The best advice is to use keys in both
137 the watches and system call rules to give the rule a meaning. If rules
138 are related or together meet a specific requirement, then give them a
139 common key name. You can use this during your investigation to select
140 only results with a specific meaning.
141 When doing an investigation, you would normally start off with the main
143 aureport output to just get an idea about what is happening on the sys‐
144 tem. This report mostly tells you about events that are hard coded by
145 the audit system such as login/out, uses of authentication, system
146 anomalies, how many users have been on the machine, and if SE Linux has
147 detected any AVCs.
148 aureport --start this-week
150 After looking at the report, you probably want to get a second view
152 about what rules you loaded that have been triggering. This is where
153 keys become important. You would generally run the key summary report
154 like this:
155 aureport --start this-week --key --summary
157 This will give an ordered listing of the keys associated with rules
159 that have been triggering. If, for example, you had a syscall audit
160 rule that triggered on the failure to open files with EPERM that had a
161 key field of access like this:
162 -a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
164 Then you can isolate these failures with ausearch and pipe the results
166 to aureport for display. Suppose your investigation noticed a lot of
167 the access denied events. If you wanted to see the files that unautho‐
168 rized access has been attempted, you could run the following command:
169 ausearch --start this-week -k access --raw | aureport --file --summary
171 This will give an ordered list showing which files are being accessed
173 with the EPERM failure. Suppose you wanted to see which users might be
174 having failed access, you would run the following command:
175 ausearch --start this-week -k access --raw | aureport --user --summary
177 If your investigation showed a lot of failed accesses to a particular
179 file, you could run the following report to see who is doing it:
180 ausearch --start this-week -k access -f /path-to/file --raw | aureport
182 --user -i
183 This report will give you the individual access attempts by person. If
185 you needed to see the actual audit event that is being reported, you
186 would look at the date, time, and event columns. Assuming the event was
187 822 and it occurred at 2:30 on 09/01/2009 and you use the en_US.utf8
188 locale, the command would look something like this:
189 ausearch --start 09/01/2009 02:30 -a 822 -i --just-one
191 This will select the first event from that day and time with the match‐
193 ing event id and interpret the numeric values into human readable val‐
194 ues.
195 The most important step in being able to do this kind of analysis is
197 setting up key fields when the rules were originally written. It should
198 also be pointed out that you can have more than one key field associ‐
199 ated with any given rule.
200
203 If you are not getting events on syscall rules that you think you
204 should, try running a test program under strace so that you can see the
205 syscalls. There is a chance that you might have identified the wrong
206 syscall.
207 If you get a warning from auditctl saying, "32/64 bit syscall mismatch
209 in line XX, you should specify an arch". This means that you specified
210 a syscall rule on a bi-arch system where the syscall has a different
211 syscall number for the 32 and 64 bit interfaces. This means that on one
212 of those interfaces you are likely auditing the wrong syscall. To solve
213 the problem, re-write the rule as two rules specifying the intended
214 arch for each rule. For example,
215 -always,exit -S openat -k access
217 would be rewritten as
219 -always,exit -F arch=b32 -S openat -k access
221 -always,exit -F arch=b64 -S openat -k access
222 If you get a warning that says, "entry rules deprecated, changing to
224 exit rule". This means that you have a rule intended for the entry fil‐
225 ter, but that filter is no longer available. Auditctl moved your rule
226 to the exit filter so that it's not lost. But to solve this so that you
227 do not get the warning any more, you need to change the offending rule
228 from entry to exit.
229
232 The following rule shows how to audit failed access to files due to
233 permission problems. Note that it takes two rules for each arch ABI to
234 audit this since file access can fail with two different failure codes
235 indicating permission problems.
236 -a always,exit -F arch=b32 -S open -S openat -F exit=-EACCES -k access
238 -a always,exit -F arch=b32 -S open -S openat -F exit=-EPERM -k access
239 -a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access
240 -a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
241
244 auditctl(8), auditd(8).
245
248 Steve Grubb
249Red Hat Aug 2014 AUDIT.RULES:(7)