auid bug

auid bug

[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

Re: auid bug

[Linda Knippers]

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

auditd/auditctl SLED10

[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

Re: auditd/auditctl SLED10

[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

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

Re: auditd/auditctl SLED10

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

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

Re: auditd/auditctl SLED10

[Linda Knippers]

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
> 

Re: auditd/auditctl SLED10

[Marcus Meissner]

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

Re: auditd/auditctl SLED10

[Lane Williams]

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

Re: auditd/auditctl SLED10

[Klaus Weidner]

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

Re: auditd/auditctl SLED10

[Marcus Meissner]

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

Re: auditd/auditctl SLED10

[Lane Williams]

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

Re: auid bug

[Steve]

> 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