audit.rules(7)
NAME
audit.rules - a set of rules loaded in the kernel audit system
DESCRIPTION
audit.rules is a file containing audit rules that will be loaded by the
audit daemon's init script whenever the daemon is started. The auditctl
program is used by the initscripts to perform this operation. The
syntax for the rules is essentially the same as when typing in an
auditctl command at a shell prompt except you do not need to type the
auditctl command name since that is implied. The audit rules come in 3
varieties: control, file, and syscall.
Control
Control commands generally involve configuring the audit system rather
than telling it what to watch for. These commands typically include
deleting all rules, setting the size of the kernel's backlog queue,
setting the failure mode, setting the event rate limit, or to tell
auditctl to ignore syntax errors in the rules and continue loading.
Generally, these rules are at the top of the rules file.
File System
File System rules are sometimes called watches. These rules are used to
audit access to particular files or directories that you may be
interested in. If the path given in the rule is a directory, then the
rule used is recursive to the bottom of the directory tree excluding
any directories that may be mount points. The syntax of these rules
generally follow this format:
-w path-to-file -p permissions -k keyname
where the permission are any one of the following:
r - read of the file
w - write to the file
x - execute the file
a - change in the file's attribute
System Call
The system call rules are loaded into a matching engine that intercepts
each syscall that all programs on the system makes. Therefore it is
very important to only use syscall rules when you have to since these
affect performance. The more rules, the bigger the performance hit. You
can help the performance, though, by combining syscalls into one rule
whenever possible.
The Linux kernel has 4 rule matching lists or filters as they are
sometimes called. They are: task, exit, user, and exclude. The task
list is checked only during the fork or clone syscalls. It is rarely
used in practice.
The exit filter is the place where all syscall and file system audit
requests are evaluated.
The user filter is used to filter (remove) some events that originate
in user space. By default, any event originating in user space is
allowed. So, if there are some events that you do not want to see, then
this is a place where some can be removed. See auditctl(8) for fields
that are valid.
The exclude filter is used to exclude certain events from being
emitted. The msgtype field is used to tell the kernel which message
types you do not want to record. This filter can remove the event as a
whole and is not selective about any other attribute. The user and exit
filters are better suited to selectively auditing events.
Syscall rules take the general form of:
-a action,list -S syscall -F field=value -k keyname
The -a option tells the kernel's rule matching engine that we want to
append a rule at the end of the rule list. But we need to specify which
rule list it goes on and what action to take when it triggers. Valid
actions are:
always - always create an event
never - never create an event
The action and list are separated by a comma but no space in between.
Valid lists are: task, exit, user, and exclude. Their meaning was
explained earlier.
Next in the rule would normally be the -S option. This field can either
be the syscall name or number. For readability, the name is almost
always used. You may give more than one syscall in a rule by specifying
another -S option. When sent into the kernel, all syscall fields are
put into a mask so that one compare can determine if the syscall is of
interest. So, adding multiple syscalls in one rule is very efficient.
When you specify a syscall name, auditctl will look up the name and get
its syscall number. This leads to some problems on bi-arch machines.
The 32 and 64 bit syscall numbers sometimes, but not always, line up.
So, to solve this problem, you would generally need to break the rule
into 2 with one specifying -F arch=b32 and the other specifying -F
arch=b64. This needs to go in front of the -S option so that auditctl
looks at the right lookup table when returning the number.
After the syscall is specified, you would normally have one or more -F
options that fine tune what to match against. Rather than list all the
valid field types here, the reader should look at the auditctl man page
which has a full listing of each field and what it means. But it's
worth mentioning a couple things.
The audit system considers uids to be unsigned numbers. The audit
system uses the number -1 to indicate that a loginuid is not set. This
means that when it's printed out, it looks like 4294967295. If you
write a rule that you wanted try to get the valid users of the system,
you need to look in /etc/login.defs to see where user accounts start.
For example, if UID_MIN is 500, then you would also need to take into
account that the unsigned representation of -1 is higher than 500. So
you would address this with the following piece of a rule:
-F auid>=500 -F auid!=4294967295
These individual checks are "anded" and both have to be true.
The last thing to know about syscall rules is that you can add a key
field which is a free form text string that you want inserted into the
event to help identify its meaning. This is discussed in more detail in
the NOTES section.
NOTES
The purpose of auditing is to be able to do an investigation periodically or whenever an incident occurs. A few simple steps in planning up front will make this job easier. The best advice is to use keys in both the watches and system call rules to give the rule a meaning. If rules are related or together meet a specific requirement, then give them a common key name. You can use this during your investigation to select only results with a specific meaning. When doing an investigation, you would normally start off with the main aureport output to just get an idea about what is happening on the system. This report mostly tells you about events that are hard coded by the audit system such as login/out, uses of authentication, system anomalies, how many users have been on the machine, and if SE Linux has detected any AVCs. aureport --start this-week After looking at the report, you probably want to get a second view about what rules you loaded that have been triggering. This is where keys become important. You would generally run the key summary report like this: aureport --start this-week --key --summary This will give an ordered listing of the keys associated with rules that have been triggering. If, for example, you had a syscall audit rule that triggered on the failure to open files with EPERM that had a key field of access like this: -a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access Then you can isolate these failures with ausearch and pipe the results to aureport for display. Suppose your investigation noticed a lot of the access denied events. If you wanted to see the files that unauthorized access has been attempted, you could run the following command: ausearch --start this-week -k access --raw | aureport --file --summary This will give an ordered list showing which files are being accessed with the EPERM failure. Suppose you wanted to see which users might be having failed access, you would run the following command: ausearch --start this-week -k access --raw | aureport --user --summary If your investigation showed a lot of failed accesses to a particular file, you could run the following report to see who is doing it: ausearch --start this-week -k access -f /path-to/file --raw | aureport --user -i This report will give you the individual access attempts by person. If you needed to see the actual audit event that is being reported, you would look at the date, time, and event columns. Assuming the event was 822 and it occurred at 2:30 on 09/01/2009 and you use the en_US.utf8 locale, the command would look something like this: ausearch --start 09/01/2009 02:30 -a 822 -i --just-one This will select the first event from that day and time with the matching event id and interpret the numeric values into human readable values. The most important step in being able to do this kind of analysis is setting up key fields when the rules were originally written. It should also be pointed out that you can have more than one key field associated with any given rule.
TROUBLESHOOTING
If you are not getting events on syscall rules that you think you should, try running a test program under strace so that you can see the syscalls. There is a chance that you might have identified the wrong syscall. If you get a warning from auditctl saying, "32/64 bit syscall mismatch in line XX, you should specify an arch". This means that you specified a syscall rule on a bi-arch system where the syscall has a different syscall number for the 32 and 64 bit interfaces. This means that on one of those interfaces you are likely auditing the wrong syscall. To solve the problem, re-write the rule as two rules specifying the intended arch for each rule. For example, -always,exit -S openat -k access would be rewritten as -always,exit -F arch=b32 -S openat -k access -always,exit -F arch=b64 -S openat -k access If you get a warning that says, "entry rules deprecated, changing to exit rule". This means that you have a rule intended for the entry filter, but that filter is no longer available. Auditctl moved your rule to the exit filter so that it's not lost. But to solve this so that you do not get the warning any more, you need to change the offending rule from entry to exit.
EXAMPLES
The following rule shows how to audit failed access to files due to permission problems. Note that it takes two rules for each arch ABI to audit this since file access can fail with two different failure codes indicating permission problems. -a always,exit -F arch=b32 -S open -S openat -F exit=-EACCES -k access -a always,exit -F arch=b32 -S open -S openat -F exit=-EPERM -k access -a always,exit -F arch=b64 -S open -S openat -F exit=-EACCES -k access -a always,exit -F arch=b64 -S open -S openat -F exit=-EPERM -k access
SEE ALSO
auditctl(8), auditd(8).
AUTHOR
Steve Grubb
Opportunity
Personal Opportunity - Free software gives you access to billions of dollars of software at no cost. Use this software for your business, personal use or to develop a profitable skill. Access to source code provides access to a level of capabilities/information that companies protect though copyrights. Open source is a core component of the Internet and it is available to you. Leverage the billions of dollars in resources and capabilities to build a career, establish a business or change the world. The potential is endless for those who understand the opportunity.
Business Opportunity - Goldman Sachs, IBM and countless large corporations are leveraging open source to reduce costs, develop products and increase their bottom lines. Learn what these companies know about open source and how open source can give you the advantage.
Free Software
Free Software provides computer programs and capabilities at no cost but more importantly, it provides the freedom to run, edit, contribute to, and share the software. The importance of free software is a matter of access, not price. Software at no cost is a benefit but ownership rights to the software and source code is far more significant.
Free Office Software - The Libre Office suite provides top desktop productivity tools for free. This includes, a word processor, spreadsheet, presentation engine, drawing and flowcharting, database and math applications. Libre Office is available for Linux or Windows.
Free Books
The Free Books Library is a collection of thousands of the most popular public domain books in an online readable format. The collection includes great classical literature and more recent works where the U.S. copyright has expired. These books are yours to read and use without restrictions.
Source Code - Want to change a program or know how it works? Open Source provides the source code for its programs so that anyone can use, modify or learn how to write those programs themselves. Visit the GNU source code repositories to download the source.
Education
Study at Harvard, Stanford or MIT - Open edX provides free online courses from Harvard, MIT, Columbia, UC Berkeley and other top Universities. Hundreds of courses for almost all major subjects and course levels. Open edx also offers some paid courses and selected certifications.
Linux Manual Pages - A man or manual page is a form of software documentation found on Linux/Unix operating systems. Topics covered include computer programs (including library and system calls), formal standards and conventions, and even abstract concepts.
