Bug 1260873 - ausearch fails to find a ppc64le record if followed by another arch
ausearch fails to find a ppc64le record if followed by another arch
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: audit (Show other bugs)
7.2
All Linux
high Severity medium
: rc
: ---
Assigned To: Steve Grubb
BaseOS QE Security Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-08 02:29 EDT by Karel Srot
Modified: 2016-06-17 07:25 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-06-17 07:24:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Srot 2015-09-08 02:29:08 EDT
Description of problem:

Depending on the order of architectures ausearch fails to find a record when ppc64le record is followed by a different architecture (or prints both when the order is opposite).

# rpm -q audit
audit-2.4.1-5.el7.ppc64le
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c0000015 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0

# ausearch -if test.log -sc io_cancel -i
<no matches>
# 
# # now lets switch record order
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c0000015 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0

# ausearch -if test.log -sc io_cancel -i
----
type=SECCOMP msg=audit(03/17/2014 13:16:35.898:760) : auid=test uid=root gid=root ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm=test sig=SIGSYS arch=ppc64le syscall=io_cancel compat=0 ip=0x7fe37deb9c09 code=kill 
type=SECCOMP msg=audit(03/17/2014 13:16:35.898:760) : auid=test uid=root gid=root ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm=test sig=SIGSYS arch=x86_64 syscall=exit_group compat=0 ip=0x7fe37deb9c09 code=kill
Comment 1 Karel Srot 2015-09-08 02:40:55 EDT
So the bug doesn't seem to be hw specific, I have reproduced it also on x86_64
But the requirement here is that both audit record have the same timestamp.

Therefore I am reducing the severity.

# rpm -q audit
audit-2.4.1-5.el7.x86_64
# ausyscall --dump | grep 231 | awk '{print $2}'
exit_group
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# ausearch -if test.log -sc exit_group
----
time->Mon Mar 17 13:16:35 2014
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# 
# vim test.log 
# cat test.log
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=c000003e syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
type=SECCOMP msg=audit(1395076595.898:760): auid=1000 uid=0 gid=0 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=3283 comm="test" sig=31 arch=80000016 syscall=231 compat=0 ip=0x7fe37deb9c09 code=0x0
# ausearch -if test.log -sc exit_group
<no matches>
Comment 3 Steve Grubb 2015-10-22 16:41:58 EDT
The way that ausearch works is that if --arch is not given, then it checks the machine that its being run on and uses what it detects to select the arch lookup table. It can only search for one arch at a time.

This is because what its doing is taking the syscall text and turning it into a number. So, if you are running this on an x86_64 machine, then running ausearch -sc io_cancel, is the same as running ausearch -sc 210.
Comment 4 Paul Moore 2016-02-29 15:53:30 EST
(In reply to Steve Grubb from comment #3)
> The way that ausearch works is that if --arch is not given, then it checks
> the machine that its being run on and uses what it detects to select the
> arch lookup table. It can only search for one arch at a time.
> 
> This is because what its doing is taking the syscall text and turning it
> into a number. So, if you are running this on an x86_64 machine, then
> running ausearch -sc io_cancel, is the same as running ausearch -sc 210.

So do we consider this a bug or no?
Comment 5 Karel Srot 2016-06-16 09:23:14 EDT
My understanding is that it is a bug. Despite the chance of having same timestamp for two records is low, it grows if we consider that logs are collected from multiple systems. But is it fair to say that log messages in comments above are artificial and it would probably require additional testing to confirm whether it happens also for real-life logs.
Comment 6 Steve Grubb 2016-06-16 09:28:20 EDT
Normally logs from multiple systems have node in the audit trail. Node+time+serial is how events are classified.
Comment 7 Ondrej Moriš 2016-06-17 07:24:35 EDT
(In reply to Steve Grubb from comment #6)
> Normally logs from multiple systems have node in the audit trail.
> Node+time+serial is how events are classified.

Let me summarize it - this issue can be hit only if there are at least two event with the same identifier. Such a situation cannot happen on a single system not used for a remote logging. If a remote logging is used, node names are part of identifiers and a probability that two events have the same timestamp _and_ sequence number _and_ node name negligible. 

Therefore after discussion with Karel I am closing this issue as NOTABUG.
Comment 8 Ondrej Moriš 2016-06-17 07:25:12 EDT
(In reply to Ondrej Moriš from comment #7)

> ...
> same timestamp _and_ sequence number _and_ node name IS negligible.

Note You need to log in before you can comment on or make changes to this bug.