F7: SELinux feature or bug?

Jim Cornette fc-cornette at insight.rr.com
Wed Jul 11 22:04:55 UTC 2007


Jeroen Lankheet wrote:
> 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.
> 

This is after fixfiles reabel in permissive mode and runlevel 1?

Filing a report with the audit logs and initial cause of the problem and 
  current browser reports might help with a resolution.

I don't think that SELinux prepared for such a problem, even though it 
unintentionally suggested the solution.

Jim




More information about the fedora-list mailing list