auid bug
I am receiving audit events with an odd auid... I am not sure if this is something wrong in the kernel or in audit. The auid I am receiving is 4294967295 (the max value for an unsigned long). The other uid/gid information is normal.
I have seen this on all audit versions since audit-1.2.3, and noticed it using the following kernels:
2.6.17-1.2293.2.2_FC6.lspp.38.i686
2.6.17-1.2293.2.2_FC6.lspp.44.i686
The first time I noticed this was after the filter_key patch I applied to audit-1.2.3, but it may have nothing to do with that patch. I mentioned it then:
https://www.redhat.com/archives/linux-audit/2006-June/msg00086.html
There is an example record from the audit dispatcher there.
These events are coming straight from the real-time audit dispatcher.
Steve
Are you sure you have pam_loginuid.so configured in the appropriate /etc/pam.d/* files, such as login and sshd?
I'm running the .41 kernel and the audit-1.2.4 tools and the auid is correct in the audit records on my system.
This is what my /etc/pam.d/login file looks like:
#%PAM-1.0
auth required pam_securetty.so auth include system-auth account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session include system-auth session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so open
-- ljk
Quoted 27 lines · Steve
I am receiving audit events with an odd auid... I am not sure if this is something wrong in the kernel or in audit. The auid I am receiving is 4294967295 (the max value for an unsigned long). The other uid/gid information is normal.
I have seen this on all audit versions since audit-1.2.3, and noticed it using the following kernels:
2.6.17-1.2293.2.2_FC6.lspp.38.i686
2.6.17-1.2293.2.2_FC6.lspp.44.i686The first time I noticed this was after the
filter_keypatch I applied to audit-1.2.3, but it may have nothing to do with that patch. I mentioned it then:https://www.redhat.com/archives/linux-audit/2006-June/msg00086.html
There is an example record from the audit dispatcher there.
These events are coming straight from the real-time audit dispatcher.
Steve
Signature · 3 lines
Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
auditd/auditctl SLED10
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
I've tried the example
auditctl -a exit,always -S open -F success=0
When I do this I get nothing in the logs. But if I add the following
auditctl -a entry,always -S open
I get all of the entries and the open failures when there is "No such file or directory", but no access violations...
Thanks for any help,
Lane
Re: auditd/auditctl SLED10
There was a bug at one point where the '-F success=0' didn't work but '-F success!=1' did work. You might want to try that as a workaround. You might also try an strace on whatever program you're using to test with to make sure there there isn't an access() system call before the open. If there is, then you'll want to audit access failures.
-- ljk
Quoted 23 lines · Lane Williams
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
I've tried the example
auditctl -a exit,always -S open -F success=0
When I do this I get nothing in the logs. But if I add the following
auditctl -a entry,always -S open
I get all of the entries and the open failures when there is "No such file or directory", but no access violations...
Thanks for any help,
Lane
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Re: auditd/auditctl SLED10
Yeah, I had tried that. There is an access syscall. From the looks of things the audit version that comes with SuSE has a few problems. I know in Red Hat it seems to work as I need it to. SuSE is also using Apparmor in place of SELinux, or at least they make it appear that way. The audit deamon also does not support file system watches.
Seems the only success=no returns that I receive are when the file does not exist. I may also have to add more to my filter in order to get what I want. Unfortunately I am stuck with SuSE and will have to continue troubleshooting until the patches come out.
Thanks,
Lane
Quoted 34 lines · Linda Knippers
There was a bug at one point where the '-F success=0' didn't work but '-F success!=1' did work. You might want to try that as a workaround. You might also try an strace on whatever program you're using to test with to make sure there there isn't an
access()system call before the open. If there is, then you'll want to audit access failures.-- ljk
Quoted 23 lines · Lane Williams
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
I've tried the example
auditctl -a exit,always -S open -F success=0
When I do this I get nothing in the logs. But if I add the following
auditctl -a entry,always -S open
I get all of the entries and the open failures when there is "No such file or directory", but no access violations...
Thanks for any help,
Lane
--
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
Re: auditd/auditctl SLED10
Quoted 5 lines · Lane Williams
Yeah, I had tried that. There is an access syscall. From the looks of things the audit version that comes with SuSE has a few problems. I know in Red Hat it seems to work as I need it to. SuSE is also using Apparmor in place of SELinux, or at least they make it appear that way. The audit deamon also does not support file system watches.
File system watches aren't supported in the upstream kernel until 2.6.18.
Quoted 4 lines
Seems the only success=no returns that I receive are when the file does not exist. I may also have to add more to my filter in order to get what I want. Unfortunately I am stuck with SuSE and will have to continue troubleshooting until the patches come out.
If you're using a 2.6.16 kernel and 1.1.3 audit tools, that seems like a mismatch. There was a 1.1.4 audit package released back in February and the release mail mentions apparmor support.
https://www.redhat.com/archives/linux-audit/2006-February/msg00036.html
You could try:
http://people.redhat.com/sgrubb/audit/audit-1.1.4-1.src.rpm
Good luck,
-- ljk
Quoted 4 lines
Thanks,
Lane
Re: auditd/auditctl SLED10
Quoted 15 lines · Linda Knippers
Quoted 5 lines · Lane Williams
Yeah, I had tried that. There is an access syscall. From the looks of things the audit version that comes with SuSE has a few problems. I know in Red Hat it seems to work as I need it to. SuSE is also using Apparmor in place of SELinux, or at least they make it appear that way. The audit deamon also does not support file system watches.
File system watches aren't supported in the upstream kernel until 2.6.18.
Quoted 4 lines
Seems the only success=no returns that I receive are when the file does not exist. I may also have to add more to my filter in order to get what I want. Unfortunately I am stuck with SuSE and will have to continue troubleshooting until the patches come out.
Quoted 4 lines
If you're using a 2.6.16 kernel and 1.1.3 audit tools, that seems like a mismatch. There was a 1.1.4 audit package released back in February and the release mail mentions apparmor support.
https://www.redhat.com/archives/linux-audit/2006-February/msg00036.html
We have integrated AppArmor support in our 1.1.3 packages. (The stuff we sent upstream for 1.1.4).
Ciao, Marcus
Re: auditd/auditctl SLED10
I downloaded each of the audit version from 1.1.4 - 1.2.1 and compiled from the tar balls...the source rpms kept bombing out on dependencies. As of 1.2.1 with the SLED 10 distro, I was able to get it to tell me permission denied when the syscall attempted an open
on /var/log/messages from an unpriviledged user.
Thanks everyone...
Lane
Quoted 25 lines · Marcus Meissner
Quoted 15 lines · Linda Knippers
Quoted 5 lines · Lane Williams
Yeah, I had tried that. There is an access syscall. From the looks of things the audit version that comes with SuSE has a few problems. I know in Red Hat it seems to work as I need it to. SuSE is also using Apparmor in place of SELinux, or at least they make it appear that way. The audit deamon also does not support file system watches.
File system watches aren't supported in the upstream kernel until 2.6.18.
Quoted 4 lines
Seems the only success=no returns that I receive are when the file does not exist. I may also have to add more to my filter in order to get what I want. Unfortunately I am stuck with SuSE and will have to continue troubleshooting until the patches come out.
Quoted 4 lines
If you're using a 2.6.16 kernel and 1.1.3 audit tools, that seems like a mismatch. There was a 1.1.4 audit package released back in February and the release mail mentions apparmor support.
https://www.redhat.com/archives/linux-audit/2006-February/msg00036.htmlWe have integrated AppArmor support in our 1.1.3 packages. (The stuff we sent upstream for 1.1.4).
Ciao, Marcus
Re: auditd/auditctl SLED10
In reply to Lane WilliamsQuoted 7 lines · Lane Williams
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
I've tried the example
auditctl -a exit,always -S open -F success=0
What base kernel version and audit patches is SLED10 using? Audit development has been active until recently and it may not have all the latest and greatest audit patches in it.
-Klaus
Re: auditd/auditctl SLED10
Quoted 5 lines · Klaus Weidner
Quoted 4 lines · Lane Williams
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
Quoted 7 lines
Quoted 3 lines
I've tried the example
auditctl -a exit,always -S open -F success=0
What base kernel version and audit patches is SLED10 using? Audit development has been active until recently and it may not have all the latest and greatest audit patches in it.
Kernel 2.6.16.21. No additional audit patches as of now.
Ciao, Marcus
Re: auditd/auditctl SLED10
In reply to Klaus WeidnerThe kernel is 2.6.16.21-0.8, and the audit version is 1.1.3-23.2.
Lane
Quoted 14 lines · Klaus Weidner
Quoted 7 lines · Lane Williams
I am using audit 1.1.3 under SuSE Enterprise 10. I was wondering if anyone could give me an idea of how to log when someone tries to open a file which they do not have access to.
I've tried the example
auditctl -a exit,always -S open -F success=0
What base kernel version and audit patches is SLED10 using? Audit development has been active until recently and it may not have all the latest and greatest audit patches in it.
-Klaus
Quoted 2 lines
Are you sure you have pam_loginuid.so configured in the appropriate
/etc/pam.d/*files, such as login and sshd?
I checked the login file and it matches yours, I am not using ssh on this machine.
Quoted 2 lines
I'm running the .41 kernel and the audit-1.2.4 tools and the auid is correct in the audit records on my system.
Most of the time, mine is correct as well. It seems to occur sporadically. Usually, a reboot will fix the problem.
Steve
Quoted 22 lines
Quoted 22 lines
I am receiving audit events with an odd auid... I am not sure if this is something wrong in the kernel or in audit. The auid I am receiving is 4294967295 (the max value for an unsigned long). The other uid/gid information is normal.
I have seen this on all audit versions since audit-1.2.3, and noticed it using the following kernels:
2.6.17-1.2293.2.2_FC6.lspp.38.i686
2.6.17-1.2293.2.2_FC6.lspp.44.i686The first time I noticed this was after the
filter_keypatch I applied to audit-1.2.3, but it may have nothing to do with that patch. I mentioned it then:https://www.redhat.com/archives/linux-audit/2006-June/msg00086.html
There is an example record from the audit dispatcher there.
These events are coming straight from the real-time audit dispatcher.
Steve