Bug 426195
Summary: | avc: denied multiple instances | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tim McConnell <timothy.mcconnell> | ||||
Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 7 | Keywords: | Reopened | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i686 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Current | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2008-01-30 19:19:10 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Tim McConnell
2007-12-19 06:41:13 UTC
You have a badly mislabeled file system touch /.autorelabel; reboot The file context of file_t indicates that you have booted a machine which was never labeled or running with selinux=0, When you turn on SELinux you have to setup the labeling for the entire machine. (In reply to comment #1) > You have a badly mislabeled file system Ok then why is SELinux not relabeling the system correctly after upgrading to newer policies? > touch /.autorelabel; reboot > > The file context of file_t indicates that you have booted a machine which was > never labeled or running with selinux=0, When you turn on SELinux you have to > setup the labeling for the entire machine. What I did is disable SELinux and reboot, then set SELinux to enforcing and rebooted. Upon rebooting SELinux relabeled the system. Thus I have two questions about your above statement: 1) If I have SELinux set to disabled or to zero, why is it still active? If someone disables it they are probably thinking SELinux is not protecting their system at all. If that is not true shouldn't the setting be called "minimal" instead of disabled? 2) Why is the FSCK command being blocked (especially if the statement you made about SELinux being disabled was correct)? If that is the only way for Linux to repair the file system if a problem is found during booting then there should be a way to allow FSCK to run without being a security hazard or being a possible source for hostile takeover by a malicious user. When selinux-policy is updated the scripts compare the previous installed selinux-policy file_context mappings to the newly installed one and then fix the contexts on the difference. It does not fully relabel as this would take too long. If SELinux is disabled, then nothing is happing. But the file context is still on disk from when the machine was running with selinux enabled. So selinux disabled means disabled. I guess fsck should be allowed to run even with bad labeling. I have no idea how you got to this labeling, as you have seen SELinux attempts to protect itself by watching for the creation of a file with a bad label. If you boot a machine with selinux disabled, it creates the /.autorelabel file which it then uses the next time you boot to trigger a relabeling of the system. From /etc/rc.sysnet # Check to see if a full relabel is needed if [ -n "$SELINUX_STATE" -a "$READONLY" != "yes" ]; then if [ -f /.autorelabel ] || strstr "$cmdline" autorelabel ; then relabel_selinux fi else if [ -d /etc/selinux -a "$READONLY" != "yes" ]; then [ -f /.autorelabel ] || touch /.autorelabel fi fi So these AVC's look like you turned on SELinux and then rebooted. The system went through and fixed the file context on disk, these avc messages were generated in the process. I will fix the fsck being allowed to read file_t problem. in the next F7 Update. Fixed in selinux-policy-2.4.6-64 Created attachment 290215 [details]
blocked processes in dmesg output
Also found these lines in /var/log/messages: Dec 20 20:53:21 timmieland setroubleshoot: [rpc.ERROR] attempt to open server connection failed: (111, 'Connection refused') Dec 20 20:52:45 timmieland kernel: audit: *NO* daemon at audit_pid=2217Dec 20 20:52:45 timmieland kernel: audit: *NO* daemon at audit_pid=2217 Bulk closing all bugs in Fedora updates in the modified state. If you bug is not fixed, please reopen. |