audit 2.3 released

Hi,

I've just released a new version of the audit daemon. It can be downloaded from http://people.redhat.com/sgrubb/audit. It will also be in rawhide soon. The ChangeLog is:

- The clone(2) man page is really clone(3), fix interpretation of clone syscall
- Add systemd support for reload (#901533)
- Allow -F msgtype on the user filter
- Add legacy support for resuming logging under systemd (#830780)
- Add legacy support for rotating logs under systemd (#916611)
- In auditd, collect SIGUSR2 info for DAEMON_RESUME events
- Updated man pages
- Update libev to 4.15
- Update syscall tables for 3.9 kernel
- Interpret MQ_OPEN events
- Add augenrules support (Burn Alting)
- Consume less stack sending audit events

I had planned calling this 2.2.4, but since the augenrules program went in, I thought this is a major release because something landed that everyone should pay attention to. In case it wasn't apparent from the thread what this does, I'll now explain it a bit.

Several people have asked for a way to deposit rules into a directory so that based on what is installed, rules can also be added. This makes it easier to have a core system that gets packages, config, and files added to make it a different kind of server or desktop. My guess is that it will be mostly used to add watches on setuid apps which can differ from machine type to machine type.

The place where these rules are stored is /etc/audit/rules.d. Compiling rules from that directory will result in a new file being written to /etc/audit/audit.rules. That means it can overwrite existing rules. Since we don't want that to happen by accident, augenrules is disabled by default.

To enable it on a SysVinit system, go into /etc/sysconfig/auditd and find the USE_AUGENRULES variable and set it to "yes". Then copy existing rules into /etc/audit/rules.d and restart the audit daemon.

For systemd based systems, copy /lib/systemd/system/auditd.service to /etc/systemd/system/auditd.service. Then find a commented out ExecStartPost variable and uncomment it. Then delete/comment out the auditctl line. The -- load option to augenrules will call auditctl for you. Also copy any existing rules into /etc/audit/rules.d so they don't get lost. Then restart auditd.

In both cases, you can check to make sure you have rules loaded with auditctl -l.

Aside from this major change, this release focused on improving the systemd support for legacy commands, such as: service auditd rotate, service auditd resume. this release also trims about 15k of stack space from logging events via pam, it updates the libev version, and it improves interpretations.

Please let me know if you run across any problems with this release.

-Steve

All,

Is there a listing somewhere that explains what various exit codes in auditd are?

For example, we are getting some exit=-17 entries in our logs, and we have narrowed it down to an init script that tries to create a directory that already exists. So, we are pretty sure exit=-17 means that a directory already exits.

It would be nice if we knew all codes and their translation, whether it be exit=-2, exit=-22, exit=-6, or exit=-17 and so on.

I have yet to find that explained anywhere. Any info would be greatly appreciated and would help us fine tune our audit.rules file.

Chad Vaughn

Isn't that just the return code of the syscall in question? Meaning, you'd need to look up the syscall in the relevant include file to see what -17 meant. Maybe auparse already does this, I'm not sure.

ausearch -i at least translates them into their posix names....

checking out /usr/include/asm-generic/errno-base.h shows:

#define EEXIST 17 /* File exists */

But if you use -i it will do it correctly across arches, etc...

----- Original Message -----

Thanks to everybody for their help.

Eric,

That file, /usr/include/asm-generic/errno-base.h, was exactly what I was looking for. Thanks!

Chad Vaughn

-----Original Message-----
From: Eric Paris [mailto:[email protected]]
Sent: Wednesday, May 01, 2013 3:45 PM
To: Peter Moody
Cc: Vaughn, Chad M; [email protected]
Subject: EXTERNAL: Re: explanation/translation of auditd exit codes

ausearch -i at least translates them into their posix names....

checking out /usr/include/asm-generic/errno-base.h shows:

#define EEXIST 17 /* File exists */

But if you use -i it will do it correctly across arches, etc...

----- Original Message -----

Hi Chad,

How are you looking at the syscall events? This is one case where grep is not your friend. Try using ausearch instead. Here's a syscall that failed and the log record was extracted with ausearch -a 1689093 where 1689093 is the audit id:

type=SYSCALL msg=audit(1367438345.734:1689093): arch=c000003e syscall=2 success=no exit=-13 a0=7f5c361ef8b0 a1=c2 a2=180 a3=7f5c361ef8b0 items=1 ppid=1 pid=3840 auid=1341 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=231 comm="fishpacker" exe="/usr/bin/fishpacker" key=61636365737301616363657373016964732D7379732D6869

This look pretty ugly. I have no idea what syscall number 2 is or what a -13 for an exit code is. But, if I do ausearch -i -a 1689093 (note the -i flag meaning "interpret") I get:

type=SYSCALL msg=audit(05/01/2013 12:59:05.734:1689093) : arch=x86_64 syscall=open success=no exit=-13(Permission denied) a0=0x7f5c361ef8b0 a1=O_RDWR|O_CREAT|O_EXCL a2=0x180 a3=0x7f5c361ef8b0 items=1 ppid=1 pid=3840 auid=blotto uid=apache gid=apache euid=apache suid=apache fsuid=apache egid=apache sgid=apache fsgid=apache tty=(none) ses=231 comm=fishpacker exe=/usr/bin/fishpacker key=access key=access key=ids-sys-hi

This is much nicer on the eyes. It was open syscall that failed because of a permission denied. I also get the arguments on how the open on the file (O_RDWR|O_CREAT|O_EXCL) was set up.

Let ausearch -i do the walking thru the audit log pages and do the mapping so you don't have to.

Best regards,

Gary Smith

Hello,

[...]

[...]

The make install rule is now installing audit.rules in the /etc/audit/rules.d directory.

What would happen on fresh installation if augenrules call is disabled and that /etc/audit/audit.rules is not existing?

Will /etc/audit/rules.d/audit.rules be called as a fallback? Or should distributions take care of shipping both /etc/audit/audit.rules and /etc/audit/rules.d/audit.rules?

What do you think?

Cheers

Laurent Bigonville

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Laurent,

I think audit.rules should revert back to being installed to /etc/audit/audit.rules.

This way we maintain Steve's intent, that the use of augenrules and /etc/audit/rules.d is the result of a conscious decision by an administrator. IE no inadvertent overwriting of /etc/audit/audit.rules during an upgrade.

Regards
Burn Alting

--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit

Hello,

What I did in Fedora is to add a post install action like this:

%post
# Copy default rules into place on new installation
if [ ! -e /etc/audit/audit.rules ] ; then
cp /etc/audit/rules.d/audit.rules /etc/audit/audit.rules
fi

This way if its a new install, you get a copy of the rules and if there are any previously existing rules, they are not overwritten.

-Steve

Thanks, yes I figured that out too, I should probably not post emails before my 1st cup of coffee on Sunday morning :)

Cheers

Laurent Bigonville