setroubleshootd AVC denials???

[Matej Cepl]

Hi,

I am afraid, my notebook got to some unrecognized state -- even 
setroubleshootd gets AVC denials and sealert cannot get 
connection! I tried relabelling but not much has changed. Yes, it 
is the same notebook as in 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215722#c15 
and I have put my audit.log on 
http://www.ceplovi.cz/matej/tmp/audit.log.bz2

Is there any hope in getting my notebook back into being 100% 
free of AVC denials?

Thanks for any reply,

Matej

[John Dennis]

On Tue, 2007-05-29 at 23:25 +0200, Matej Cepl wrote:
> Hi,
>
> I am afraid, my notebook got to some unrecognized state -- even 
> setroubleshootd gets AVC denials and sealert cannot get 
> connection! I tried relabelling but not much has changed. Yes, it 
> is the same notebook as in 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=215722#c15

updated bz with instructions on how to check if setroubleshootd is
running which is the most plausible explanation for why sealert cannot
connect.
> and I have put my audit.log on 
> http://www.ceplovi.cz/matej/tmp/audit.log.bz2

Hmm... I get: 403 Permission denied

Please add data like this as attachments to the bugzilla, that's the
only way we can track it.

[Matej Cepl]

On 2007-05-29, 21:47 GMT, John Dennis wrote:
> updated bz with instructions on how to check if setroubleshootd 
> is running which is the most plausible explanation for why 
> sealert cannot connect.

Nonsense, of course it is and it was running. sealert has been 
now for the last five minutes trying to get connection to 
setroubleshootd (or wherever, showing ``Server load'' message all 
the time).
> > and I have put my audit.log on 
> > http://www.ceplovi.cz/matej/tmp/audit.log.bz2
>
> Hmm... I get: 403 Permission denied

That should be fixed and it has been attached to the bug 215722 
as well (although, we should really make from it a new bug; this 
one used to be around selinux problems with postfix -- which are 
not fixed anyway).

Matej

[Daniel J Walsh]

Matej Cepl wrote:
> On 2007-05-29, 21:47 GMT, John Dennis wrote:
> > updated bz with instructions on how to check if setroubleshootd 
> > is running which is the most plausible explanation for why 
> > sealert cannot connect.
>
> Nonsense, of course it is and it was running. sealert has been 
> now for the last five minutes trying to get connection to 
> setroubleshootd (or wherever, showing ``Server load'' message all 
> the time).
> > > and I have put my audit.log on 
> > > http://www.ceplovi.cz/matej/tmp/audit.log.bz2
> >
> > Hmm... I get: 403 Permission denied
>
> That should be fixed and it has been attached to the bug 215722 
> as well (although, we should really make from it a new bug; this 
> one used to be around selinux problems with postfix -- which are 
> not fixed anyway).
>
> Matej
>
> --
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

What platform are you seeing these on.

execmem execstack should not be required for setroubleshoot.

Looks like avahi is trying to communicate with dbus running as 
unconfined_execmem_t?

You seem to be running a script from hal called hibernate?

[Matej Cepl]

On 2007-05-30, 17:10 GMT, Daniel J Walsh wrote:
> What platform are you seeing these on.

i386, actually Dell Inspiron 2200 (a cheap notebook)
> execmem execstack should not be required for setroubleshoot.

What can I say?
> Looks like avahi is trying to communicate with dbus running as 
> unconfined_execmem_t?

Again, there shouldn't be anything special about avahi.
> You seem to be running a script from hal called hibernate?

Actually, this might be the only modification of the system -- 
I use a modified kernel from http://mhensler.de/swsusp/ (the only 
difference from stock kernels should be suspend2 patch -- 
http://www.suspend2.net/ ) and it has some modified utilities as 
well, among which is a shell script hibernate (switching off 
services, removing modules, and in other ways making computer 
palatable for suspending process) and modified pm-utils, which 
are probably running hibernate instead of whatever-is-a-standard 
suspend process in out-of-stock Fedora. If pm-utils are using hal 
to run hibernate, I have no idea.

Am I the only one running suspend2 with SELinux on?

Does it make any sense?

Matej