Hi Pierre. On Wednesday 25 Mar 2009 15:26:21 Ritesh Raj Sarraf wrote: > > The cause of the problem seems to be a signal (SIGALRM) received by the > > Python code. Unfortunaly, Python is a bit stupid and sends a > > KeyboardInterrupt where the problem is really a signal .. > > I have contacted setroubleshoot upstream, but so far we haven't found > > why this signal is sent (we suspect glib internals, like timers, though > > it does not explain why the Python code receives it. > > > Yes, it is a tough one. :-( > > Currently, on my setup, on SELinux violations, I do see the notification in > the system tray, but then when I click on it, the browser doesn't open. > > I have been trying to look at all possible places to figure out why this is > happening, but no luck yet. > > I'll keep trying to see if I can provide more info on both the issues.
I had been thinking for the past 2 weeks that probably we should tag the
KeyboardInterrupt problem as obsolete because I hadn't see it happen again
soon.
But today again, I saw the same message. Interestingly, this time, it happens
in a different module.
Apr 12 20:41:50 champaran hald: mounted /dev/sdb1 on behalf of uid 1000
Apr 12 20:41:50 champaran setroubleshoot: SELinux is preventing hal-storage-
mou (hald_t) "connectto" unconfined_t. For complete SELinux messages. run
sealert -l 6805cd48-ecd8-4b1d-bc15-9888145b7baa
Apr 12 20:41:50 champaran setroubleshoot: SELinux prevented mount from reading
from the urandom device. For complete SELinux messages. run sealert -l
f79de13f-e37a-42af-a848-d3db94f8467e
Apr 12 20:42:04 champaran setroubleshoot: [program.ERROR] audit
event#012node=champaran type=AVC msg=audit(1239549124.211:698): avc: denied
{ execmem } for pid=3915 comm="knotify4"
scontext=unconfined_u:unconfined_r:unconfined_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0
tclass=process#012#012node=champaran type=SYSCALL
msg=audit(1239549124.211:698): arch=40000003 syscall=192 success=no
exit=-1396977664 a0=0 a1=801000 a2=7 a3=20022 items=0 ppid=1 pid=3915
auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000
sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="knotify4"
exe="/usr/bin/knotify4" subj=unconfined_u:unconfined_r:unconfined_t:s0
key=(null)
Traceback (most recent call last):
File "/var/lib/python-support/python2.5/setroubleshoot/analyze.py", line
350, in auto_save_callback
self.save()
File "/var/lib/python-support/python2.5/setroubleshoot/analyze.py", line
326, in save
self.prune()
File "/var/lib/python-support/python2.5/setroubleshoot/analyze.py", line
257, in prune
self.sigs.signature_list.sort(lambda a,b: cmp(a.last_seen_date,
b.last_seen_date))
File "/var/lib/python-support/python2.5/setroubleshoot/analyze.py", line
257, in <lambda>
self.sigs.signature_list.sort(lambda a,b: cmp(a.last_seen_date,
b.last_seen_date))
KeyboardInterrupt
I have a question here.
Usual violation are syslogged in the following format:
Apr 9 21:35:00 champaran setroubleshoot: SELinux is preventing knotify4 from
making the program stack executable. For complete SELinux messages. run
sealert -l 133a85f0-064f-469e-9bc7-a62185d5b35b
In today's case, the format is different:
Apr 12 20:42:04 champaran setroubleshoot: [program.ERROR] audit
event#012node=champaran type=AVC msg=audit(1239549124.211:698): avc: denied
{ execmem } for pid=3915 comm="knotify4"
Look at the "program.ERROR" part. That looks to be the error. And this is
immediately followed by the above exception.
I think this violation wasn't filtered properly or something weired happened
with the violation, that then further made the rest of the setroubleshoot
assumptions break.
But still, that shouldn't throw a KeyboardInterrupt.
The logging to syslog is with setroubleshoot. Probably that should be the
starting poiint to see why and when setroubleshoot logs a "program.ERROR".
I think it might just be needing a check, that when a program.ERROR occurs, it
should do something.
Need to check the sources...
Hmm!!
I'm not sure. Probably, maybe, verify_avc() in src/avc_audit.py might have
some pointers.
Ritesh
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
signature.asc
Description: This is a digitally signed message part.
