Re: F7: SELinux feature or bug?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux