9:08 a.m.
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
10:19 a.m.
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
Steve wrote:
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
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
2:44 p.m.
New subject: 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
3:08 p.m.
New subject: 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
Lane Williams wrote:
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
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
7:14 a.m.
New subject: 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
On Thu, 2006-07-20 at 16:08 -0400, Linda Knippers wrote:
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
Lane Williams wrote:
> 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
> Linux-audit(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
9:31 a.m.
New subject: auditd/auditctl SLED10
Lane Williams wrote:
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.
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
Thanks,
Lane
9:35 a.m.
New subject: auditd/auditctl SLED10
On Fri, Jul 21, 2006 at 10:31:22AM -0400, Linda Knippers wrote:
Lane Williams wrote:
> 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.
> 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
We have integrated AppArmor support in our 1.1.3 packages. (The
stuff we sent upstream for 1.1.4).
Ciao, Marcus
3:49 p.m.
New subject: 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
On Fri, 2006-07-21 at 16:35 +0200, Marcus Meissner wrote:
On Fri, Jul 21, 2006 at 10:31:22AM -0400, Linda Knippers wrote:
> Lane Williams wrote:
> > 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.
>
> > 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
We have integrated AppArmor support in our 1.1.3 packages. (The
stuff we sent upstream for 1.1.4).
Ciao, Marcus
7:54 p.m.
New subject: auditd/auditctl SLED10
On Thu, Jul 20, 2006 at 03:44:07PM -0400, Lane Williams wrote:
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
1:02 a.m.
New subject: auditd/auditctl SLED10
On Thu, Jul 20, 2006 at 07:54:26PM -0500, Klaus Weidner wrote:
On Thu, Jul 20, 2006 at 03:44:07PM -0400, Lane Williams wrote:
> 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.
Kernel 2.6.16.21. No additional audit patches as of now.
Ciao, Marcus
7:04 a.m.
New subject: auditd/auditctl SLED10
The kernel is 2.6.16.21-0.8, and the audit version is 1.1.3-23.2.
Lane
On Thu, 2006-07-20 at 19:54 -0500, Klaus Weidner wrote:
On Thu, Jul 20, 2006 at 03:44:07PM -0400, Lane Williams wrote:
> 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
11:04 a.m.
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.
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
> 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
7039
days inactive
7043
days old
linux-audit@lists.linux-audit.osci.io
11 comments
5 participants
participants (5)
-
Klaus Weidner -
Lane Williams -
Linda Knippers -
Marcus Meissner -
Steve