Bug 437699 - No error messages from kismet
No error messages from kismet
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-16 13:43 EDT by Göran Uddeborg
Modified: 2008-11-10 08:32 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-10 08:32:53 EST
Type: ---
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 Göran Uddeborg 2008-03-16 13:43:15 EDT
Description of problem:
Running kismet witout having configured it properly with a source should give
error messages.  But when I did this it just terminated silently.  After
switching to permissive mode, I did get the error messages.

Strace:ing shows that kismet is writing the messages to stderr, and the system
calls succeeds.  And I don't get any AVC messages in audit.log.  But since
switching to permissive mode allows the messages, I suppose it has to be SELinux
blocking it anyway, somehow.

Version-Release number of selected component (if applicable):
selinux-policy-3.0.8-93.fc8.noarch
selinux-policy-targeted-3.0.8-93.fc8.noarch
kismet-0.0.2007.10.R1-0.fc8.x86_64
Comment 1 Daniel Walsh 2008-03-17 08:55:27 EDT
What avc messages were generated?
Comment 2 Göran Uddeborg 2008-03-17 10:21:46 EDT
I can imagine that is a bit of a standard question from you on those reports. 
And for good reason I suspect.  :-)

But in this case, I actually said in my second paragraph that I don't get any
avc messages.  And according to strace the write system calls succeed.  But
still, nothing is written in the xterm where I run the command.  I do not know
what functionality in SELinux that could cause this behaviour.
Comment 3 Daniel Walsh 2008-03-17 11:02:44 EDT
semodule -DB
Will turn off all "dontaudit" rules.

Then run kismet.

semodule -B 
will turn dontaudit rules back on.
Comment 4 Göran Uddeborg 2008-03-17 11:18:18 EDT
Yes, with that I did get some messages:

time->Mon Mar 17 16:13:50 2008
type=SYSCALL msg=audit(1205766830.050:1324): arch=c000003e syscall=59
success=yes exit=0 a0=6268a0 a1=7fff49de6140 a2=632000 a3=0 items=0 ppid=1136
pid=3534 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
tty=(none) comm="kismet" exe="/usr/bin/kismet"
subj=unconfined_u:system_r:kismet_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1205766830.050:1324): avc:  denied  { read write } for 
pid=3534 comm="kismet" path="/dev/pts/1" dev=devpts ino=3
scontext=unconfined_u:system_r:kismet_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_devpts_t:s0 tclass=chr_file
type=AVC msg=audit(1205766830.050:1324): avc:  denied  { read write } for 
pid=3534 comm="kismet" path="/dev/pts/1" dev=devpts ino=3
scontext=unconfined_u:system_r:kismet_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_devpts_t:s0 tclass=chr_file
type=AVC msg=audit(1205766830.050:1324): avc:  denied  { read write } for 
pid=3534 comm="kismet" path="/dev/pts/1" dev=devpts ino=3
scontext=unconfined_u:system_r:kismet_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_devpts_t:s0 tclass=chr_file
type=AVC msg=audit(1205766830.050:1324): avc:  denied  { read write } for 
pid=3534 comm="kismet" name="1" dev=devpts ino=3
scontext=unconfined_u:system_r:kismet_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unconfined_devpts_t:s0 tclass=chr_file
Comment 5 Daniel Walsh 2008-03-17 15:41:30 EDT
You can allow this for now by executing 

# audit2allow -M mypol -i /var/log/audit/audit.log 
# semodule -i mypol.pp

Fixed in selinux-policy-3.0.8-94.fc8

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