Bug 423961

Summary: sealert -a fails to find alerts in log file
Product: [Fedora] Fedora Reporter: John Dennis <jdennis>
Component: setroubleshootAssignee: John Dennis <jdennis>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: dwalsh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-06-08 02:57:03 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
valid input none

Description John Dennis 2007-12-13 19:52:54 UTC
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-04 01:58:52 UTC
Created attachment 290810 [details]
valid input

Comment 2 John Dennis 2008-01-04 02:00:36 UTC
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 04:11:32 UTC
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-08 02:57:03 UTC
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.