9:29 a.m.
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
2:05 p.m.
New subject: explanation/translation of auditd exit codes
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
2:15 p.m.
New subject: explanation/translation of auditd exit codes
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3:45 p.m.
New subject: 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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3:52 p.m.
New subject: explanation/translation of auditd exit codes
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(a)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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
3:16 p.m.
New subject: explanation/translation of auditd exit codes
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
4:43 a.m.
New subject: audit.rules file [Was: audit 2.3 released]
Le Wed, 01 May 2013 10:29:07 -0400,
Steve Grubb <sgrubb(a)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
8:32 a.m.
New subject: audit.rules file [Was: audit 2.3 released]
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(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:17 a.m.
New subject: audit.rules file [Was: audit 2.3 released]
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
9:02 a.m.
New subject: audit.rules file [Was: audit 2.3 released]
Le Mon, 06 May 2013 09:17:18 -0400,
Steve Grubb <sgrubb(a)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
4247
days inactive
4252
days old
linux-audit@lists.linux-audit.osci.io
9 comments
7 participants
participants (7)
-
Burn Alting -
Eric Paris -
Laurent Bigonville -
Peter Moody -
Smith, Gary R -
Steve Grubb -
Vaughn, Chad M