6:25 p.m.
Hello,
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
tomorrow. The Changelog is:
- adjust file perms of newly created log file in auditd
- fix 2 memory leaks and an out of bounds access in auditd
- fix case where auditd was closing netlink descriptor too early
- fix watch rules not to take field arguments in auditctl
- fix bug where inode, devmajor, devminor, exit, and success fields in
auditctl rules were not getting the correct value stored
This is a bug fix release. There was a big bug found by Amy Griffis of HP
where several fields values are set to 0 before being sent into the kernel.
The fields affected are: inode, devmajor, devminor, exit, and success. Thanks
for reporting it!
Please let me know if there are any problems.
-Steve
11:48 p.m.
- fix bug where inode, devmajor, devminor, exit, and success fields
in
auditctl rules were not getting the correct value stored
For auditctl, what are acceptable values for the -F success flag?
0, 1, yes, no?
1. success=no and success=yes seem to result in the same filter rule being
added
If I do:
# auditctl -a exit,always -S chmod -F success=no
# auditctl -l
AUDIT_LIST: exit,always success=0 syscall=chmod
But if I do:
# auditctl -D
# auditctl -a exit,always -S chmod -F success=yes
# auditctl -l
AUDIT_LIST: exit,always success=0 syscall=chmod
Notice either way, the rule being added has success=0.
2. If I add a rule with the flags success=0 and success=1, they seem fine
when I list them.
But I get the same behavior whether I passed in a 0 or 1.
'auditctl -a exit,always -S chmod -F success=0' captures only successful
syscalls.
# auditctl -l
AUDIT_LIST: exit,always success=0 syscall=chmod
type=SYSCALL msg=audit(1124855948.374:10067): arch=14 syscall=15
success=yes exit=0 a0=1001a8b0 a1=1ff a2=0 a3=fffffffffefefeff items=1
pid=15044 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 comm="chmod" exe="/bin/chmod"
'auditctl -a exit,always -S chmod -F success=1' captures only successful
syscalls.
# auditctl -l
AUDIT_LIST: exit,always success=1 (0x1) syscall=chmod
type=SYSCALL msg=audit(1124855984.507:10070): arch=14 syscall=15
success=yes exit=0 a0=1001a8b0 a1=1ff a2=0 a3=fffffffffefefeff items=1
pid=15051 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500
sgid=500 fsgid=500 comm="chmod" exe="/bin/chmod"
'auditctl -a exit,always -S chmod -F success!=0' captures only unsuccessful
syscalls
type=SYSCALL msg=audit(1124856028.814:10073): arch=14 syscall=15 success=no
exit=-1 a0=1001a8b0 a1=16d a2=a a3=10003490 items=1 pid=15059 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
comm="chmod" exe="/bin/chmod"
'auditctl -a exit,always -S chmod -F success!=1' captures only unsuccessful
syscalls.
type=SYSCALL msg=audit(1124856071.099:10083): arch=14 syscall=15 success=no
exit=-1 a0=1001a8b0 a1=16d a2=a a3=10003490 items=1 pid=15069 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
comm="chmod" exe="/bin/chmod"
3. Should -1 be an acceptable value? Currently it is accepted:
# auditctl -a exit,always -S chmod -F success=-1
# auditctl -l
AUDIT_LIST: exit,always success=-1 (0xffffffff) syscall=chmod
No watches
Only successful syscalls result in records which is opposite of what I was
expecting.
The following is an example audit record:
type=SYSCALL msg=audit(1124853111.231:9988): arch=14 syscall=15 success=yes
exit=0 a0=1001a8b0 a1=1ff a2=32000000 a3=fffffffffefefeff items=1 pid=14770
auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500
fsgid=500 comm="chmod" exe="/bin/chmod"
If I use the rule:
'auditctl -a exit,always -S chmod -f success!=-1'
Only unsuccessful syscall result in audit records:
type=SYSCALL msg=audit(1124854274.322:10026): arch=14 syscall=15 success=no
exit=-1 a0=1001a8b0 a1=16d a2=a a3=10003490 items=1 pid=14884 auid=500
uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500
comm="chmod" exe="/bin/chmod"
I've found similar problems with the 'exit' flag and am still
investigating.
-debbie
9:40 a.m.
On Wednesday 24 August 2005 00:48, Debora Velarde wrote:
For auditctl, what are acceptable values for the -F success flag?
0, 1, yes, no?
1 & 0. I have updated the man page for 1.0.4 that explains it. i supposed I
might be able to check the value for yes/no true/false. But right now, its 1
or 0.
1. success=no and success=yes seem to result in the same filter rule
being
added
This is because atoi of yes is 0.
2. If I add a rule with the flags success=0 and success=1, they seem
fine
when I list them.
Right.
But I get the same behavior whether I passed in a 0 or 1.
There is a kernel bug in my opinion (auditsc.c):
442 case AUDIT_SUCCESS:
443 if (ctx && ctx->return_valid)
444 result = (ctx->return_valid == AUDITSC_SUCCESS);
445 break;
This doesn't use the value that was passed into the kernel. I think this
should be:
442 case AUDIT_SUCCESS:
443 if (ctx && ctx->return_valid)
444 result = (ctx->return_valid == AUDITSC_SUCCESS) == value;
445 break;
3. Should -1 be an acceptable value?
I guess not if we add the value check into the kernel. Only 1 & 0 should be
permitted.
I've found similar problems with the 'exit' flag and am
still
investigating.
The exit flag is compared in the kernel. Offhand I don't see a bug with it. If
you do see something, let us know.
-Steve
1:22 p.m.
> I've found similar problems with the 'exit' flag and am still
> investigating.
The exit flag is compared in the kernel. Offhand I don't see a bug
with it. If
you do see something, let us know.
I've confirmed that
-F exit=0
-F exit!=0
-F exit=3
-F exit!=3
All seem to be working fine. The problem I was seeing last night was
because the return code from my syscall was different than I was originally
expecting.
-debbie
10:04 a.m.
On Tue, 2005-08-23 at 23:48 -0500, Debora Velarde wrote:
For auditctl, what are acceptable values for the -F success flag?
0, 1, yes, no?
They all have the same effect -- the parameter is ignored.
The 'success' filter matches when the system call was successful.
I thought there was a 'failure' filter too, but that doesn't appear to
be the case.
--
dwmw2
11:59 a.m.
On Wednesday 24 August 2005 11:04, David Woodhouse wrote:
I thought there was a 'failure' filter too, but that
doesn't appear to
be the case.
The easiest thing to do is just add the == value to the comparison. This would
let people do something like success!=yes or success=no to test for failure.
-Steve
12:07 p.m.
On Wed, 2005-08-24 at 12:59 -0400, Steve Grubb wrote:
The easiest thing to do is just add the == value to the comparison.
This would
let people do something like success!=yes or success=no to test for failure.
Seems like a reasonable feature to add if there's consensus on it. I'm
investigating one or two other things which may require an updated
kernel anyway, so would include it then.
--
dwmw2
12:48 p.m.
linux-audit-bounces(a)redhat.com wrote on 08/24/2005 12:07:49 PM:
On Wed, 2005-08-24 at 12:59 -0400, Steve Grubb wrote:
> The easiest thing to do is just add the == value to the
comparison. This would
> let people do something like success!=yes or success=no to test for
failure.
Seems like a reasonable feature to add if there's consensus on it. I'm
investigating one or two other things which may require an updated
kernel anyway, so would include it then.
We could also just change the man page to state the following usage:
-F success=1 - to audit successful syscalls
-F success!=1 - to audit unsuccessful syscalls
7059
days inactive
7061
days old
linux-audit@lists.linux-audit.osci.io
7 comments
3 participants
participants (3)
-
David Woodhouse -
Debora Velarde -
Steve Grubb