F7: SELinux feature or bug?

[Jeroen Lankheet]

Bruno Wolff III wrote:
>>> it's ready relabeling or if it's doing anything at all.
>>>       
>> Open another terminal while it is running, and check the output of the
>> `top` command - this only works if you _can_ get to other terminals at
>> the same time, which I believe is not true in runlevel 1, or when
>> rebooting.
>>     
>
> If you are doing an auto relabel you won't be able to login. The whole point
> of doing the relabel at that point is that it is before init has started up
> processes labelled incorrectly.
>
> What you could do if you want to keep doing stuff through a relabel, is
> change to permissive mode, run fixfiles restore /, reboot when its done, change
> back to enforcing mode.
>
> That process I think can still hit some corner cases where files might be
> left incorrectly labelled. But you can run a verify afterwards to check.
>
>   
Thanks for the help so far guys, and sorry for the lousy subject.

I booted into runlevel 1 and saw the relabel doing  it's work.
Then I could actually boot my system and login again without having to
disable selinux as a kernel parameter. But selinux was still in
permissive mode.
The SELinux troubleshooter mentioned some alerts; denials and
potentially mislabeled files. So I switched to enforcing mode, and then 
immediately all kinds of (more or less expected) problems start. The 
system logs me out 10 seconds after being logged in.
So now I'm back in permissive mode.
So the next challenge is that I should 'make the troubleshooter happy'.
But this is the part where my selinux knowledge is falling short.
The attached file contains the  troubleshooter alerts.
How do I create a local policy for these selinux denials? I don't know
what the complained files are for.

Regards,
Jeroen.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: selinux_alerts.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070711/6c6131c4/attachment-0001.txt>