Bug 423961 - sealert -a fails to find alerts in log file
sealert -a fails to find alerts in log file
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: setroubleshoot (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: John Dennis
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-13 14:52 EST by John Dennis
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

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


Attachments (Terms of Use)
valid input (2.24 KB, text/plain)
2008-01-03 20:58 EST, John Dennis
no flags Details

  None (edit)
Description John Dennis 2007-12-13 14:52:54 EST
From Dan Walsh in a private email:

Analyzing this file shows no alerts?

audit(1197531599.198:3): avc:  denied  { execute } for  pid=2580 comm="sh"
name="modprobe" dev=md127 ino=1759242 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:insmod_exec_t:s0 tclass=file
audit(1197531599.198:4): avc:  denied  { read } for  pid=2580 comm="sh"
name="modprobe" dev=md127 ino=1759242 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:insmod_exec_t:s0 tclass=file
audit(1197531599.198:5): avc:  denied  { execute_no_trans } for  pid=2580
comm="sh" path="/sbin/modprobe" dev=md127 ino=1759242
scontext=system_u:system_r:pppd_t:s0 tcontext=system_u:object_r:insmod_exec_t:s0
tclass=file
audit(1197531599.198:6): avc:  denied  { read } for  pid=2580 comm="modprobe"
name="modprobe.conf" dev=md127 ino=201730 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
audit(1197531599.198:7): avc:  denied  { getattr } for  pid=2580 comm="modprobe"
path="/etc/modprobe.conf" dev=md127 ino=201730
scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_conf_t:s0 tclass=file
audit(1197531599.199:8): avc:  denied  { search } for  pid=2580 comm="modprobe"
name="modules" dev=md127 ino=881665 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_object_t:s0 tclass=dir
audit(1197531599.199:9): avc:  denied  { read } for  pid=2580 comm="modprobe"
name="modules.dep" dev=md127 ino=897066 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_dep_t:s0 tclass=file
audit(1197531599.199:10): avc:  denied  { getattr } for  pid=2580
comm="modprobe" path="/lib/modules/2.6.23.8-63.fc8/modules.dep" dev=md127
ino=897066 scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_dep_t:s0 tclass=file
audit(1197531599.201:11): avc:  denied  { read write } for  pid=2580
comm="modprobe" name="atm.ko" dev=md127 ino=901426
scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_object_t:s0 tclass=file
audit(1197531599.201:12): avc:  denied  { lock } for  pid=2580 comm="modprobe"
path="/lib/modules/2.6.23.8-63.fc8/kernel/net/atm/atm.ko" dev=md127 ino=901426
scontext=system_u:system_r:pppd_t:s0
tcontext=system_u:object_r:modules_object_t:s0 tclass=file
Comment 1 John Dennis 2008-01-03 20:58:52 EST
Created attachment 290810 [details]
valid input
Comment 2 John Dennis 2008-01-03 21:00:36 EST
The problem was the audit records were not well formed audit messages, they were
missing the audit record type (e.g. they should all have begun with type=AVC). 

An audit record MUST specify it's type, if the record type is not present we
ignore it because we don't know how to interpret the audit record.

I've attached a file showing what the data should have looked like. It scans
properly.

How did you get this textural data? If it's coming from some place we expect to
be able to parse we may to special case some logic or fix what is generating it,
but otherwise my inclination  is that's it's bad input and the lines were
properly ignored.
Comment 3 Bug Zapper 2008-05-14 00:11:32 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Brennan Ashton 2008-06-07 22:57:03 EDT
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

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