audit 2.3 released

audit 2.3 released

[Steve Grubb]

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

explanation/translation of auditd exit codes

[Vaughn, Chad M]

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

Re: explanation/translation of auditd exit codes

[Peter Moody]

[-- Attachment #1.1: Type: text/plain, Size: 1018 bytes --]

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.
On May 1, 2013 12:10 PM, "Vaughn, Chad M" <chad.m.vaughn@lmco.com> wrote:

> 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
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
>

[-- Attachment #1.2: Type: text/html, Size: 1452 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: explanation/translation of auditd exit codes

[Eric Paris]

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 -----
> 
> 
> 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.
> On May 1, 2013 12:10 PM, "Vaughn, Chad M" < chad.m.vaughn@lmco.com > wrote:
> 
> 
> 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
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

RE: explanation/translation of auditd exit codes

[Vaughn, Chad M]

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:eparis@redhat.com] 
Sent: Wednesday, May 01, 2013 3:45 PM
To: Peter Moody
Cc: Vaughn, Chad M; linux-audit@redhat.com
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 -----
> 
> 
> 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.
> On May 1, 2013 12:10 PM, "Vaughn, Chad M" < chad.m.vaughn@lmco.com > wrote:
> 
> 
> 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
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: explanation/translation of auditd exit codes

[Smith, Gary R]

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

On 5/1/13 12:05 PM, "Vaughn, Chad M" <chad.m.vaughn@lmco.com> wrote:

>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
>
>--
>Linux-audit mailing list
>Linux-audit@redhat.com
>https://www.redhat.com/mailman/listinfo/linux-audit

audit.rules file [Was: audit 2.3 released]

[Laurent Bigonville]

Le Wed, 01 May 2013 10:29:07 -0400,
Steve Grubb <sgrubb@redhat.com> a écrit :

> Hi,
Hello,

[...]
> 
> 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.
[...]

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
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit.rules file [Was: audit 2.3 released]

[Burn Alting]

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

On Sun, 2013-05-05 at 11:43 +0200, Laurent Bigonville wrote:
> Le Wed, 01 May 2013 10:29:07 -0400,
> Steve Grubb <sgrubb@redhat.com> a écrit :
> 
> > Hi,
> Hello,
> 
> [...]
> > 
> > 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.
> [...]
> 
> 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
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit.rules file [Was: audit 2.3 released]

[Steve Grubb]

Hello,

On Sunday, May 05, 2013 11:43:57 AM Laurent Bigonville wrote:
> > 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.
> 
> [...]
> 
> 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?

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

Re: audit.rules file [Was: audit 2.3 released]

[Laurent Bigonville]

Le Mon, 06 May 2013 09:17:18 -0400,
Steve Grubb <sgrubb@redhat.com> a écrit :

> 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.

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