Richard England wrote:
Terry - Fedora Core wrote:
As I reported on another thread, SELinux has caused me trouble and
blocked access to my hard disks.
To solve the problem, I set SELinux to "permissive" mode. Am I
positive that SELinux caused the problem of not being able access the
hard disks. No. But then when I set SELinux to permissive mode the
problem disappeared. Not proof, but very strong evidence.
My question:
Should I enable SELinux again?
What do I gain if I do?
Will the gain be greater than the loss of accessing my computer hard
disks?
And if I do, how do I try to prevent it from locking me out of the
hard disks again?
How do I determine what caused SELinux to block access, how much
trouble is it to change SELinux to prevent it from doing that again?
Your insights are appreciated.
Terry
You need to provide more solid details around "...blocked access to my
hard disks." What error messages are you seeing? Some one on this
list might
The error messages were along the lines that an application could not
write to it's resource file in it's hidden directory in my home directory.
Also, Konqueror simply refused to open any directories whatsoever. It
displayed the directory structure in the navigation panel, but it would
not allow access to any directory, even directories under my home
directory. Nor would it allow access to other hard disks on the system -
hard disks other than the hard disk that FEdora Core 8 is installed on.
The computer was still working, but ALL directories and ALL files were
simply not accesable, either by Konqueror or any other application. Even
when I used File Manager (Konqueror) in super user mode or the super
user terminal. I simply got error messages that I did not have
sufficient permission to access the directory/file - even the super user
(root) got the same message. I attributed t6his to SELinux based on the
simple logic that SELinux was giving me the error messages relating to
blocking access to something or other. See SELinux error reports below.
be able to assist you. Is SELinux involved? Probably, given your
experience but how is yet to be determine. It might be as simple as
a need to relabel your file system ("touch /.autorelabel" and reboot.
), but provide more detail and someone can help tell you if that is
your problem
I've been running F7 and F8 with SElinux enabled for as long as they
have both been out and have had not difficulties. So it is possible.
I copied the SELinux Troubleshooter reports on another thread, but they
don't seem to have made it to the list so I'll copy them below. They
make no sense to me. It references something about labeling problems,
but I did not label anything. I would expect the installation program to
apply appropriate labels to everything that the user would need to do to
download and install and configure the system for normal use so that
SELinux would not need to complain about such things. (Note the octal
IDs below have been randomly changed by me - I get nervous when I see
such information being made public :-) )
Terry
SELinux Trouble Reports follow - 4 (converted to text from pdf by
pdftotext)
Summary SELinux is preventing gdm (xdm_t) "execute" to <Unknown>
(rpm_exec_t). Detailed Description SELinux denied access requested by
gdm. It is not expected that this access is required by gdm and this
access may signal an intrusion attempt. It is also possible that the
specific version or configuration of the application is causing it to
require additional access. Allowing Access Sometimes labeling problems
can cause SELinux denials. You could try to restore the default system
file context for <Unknown>, restorecon -v <Unknown> If this does not
work, there is currently no automatic way to allow this access. Instead,
you can generate a local policy module to allow this access - see
http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
disable SELinux protection altogether. Disabling SELinux protection is
not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information Source Context Target Context Target Objects
Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { execute
} for comm=gdm dev=sda7 name=rpm pid=3107
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tclass=file
tcontext=system_u:object_r:rpm_exec_t:s0
system_u:system_r:xdm_t:s0-s0:c0.c1023 system_u:object_r:rpm_exec_t:s0
None [ file ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
Oct 30 13:55:12 EDT 2007 i686 i686 7 Wed 06 Feb 2008 01:50:35 PM EST Thu
07 Feb 2008 10:26:00 AM EST 41e3c4c1-b5da-4c6a-8917-01b4013c448f
Summary SELinux is preventing gdm (xdm_t) "getattr" to /bin/rpm
(rpm_exec_t). Detailed Description SELinux denied access requested by
gdm. It is not expected that this access is required by gdm and this
access may signal an intrusion attempt. It is also possible that the
specific version or configuration of the application is causing it to
require additional access. Allowing Access Sometimes labeling problems
can cause SELinux denials. You could try to restore the default system
file context for /bin/rpm, restorecon -v /bin/rpm If this does not work,
there is currently no automatic way to allow this access. Instead, you
can generate a local policy module to allow this access - see
http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
disable SELinux protection altogether. Disabling SELinux protection is
not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information Source Context Target Context Target Objects
Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { getattr
} for comm=gdm dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0
fsuid=0 gid=0 items=0 path=/bin/rpm pid=3107
scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 sgid=0
subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 suid=0 tclass=file
tcontext=system_u:object_r:rpm_exec_t:s0 tty=(none) uid=0
system_u:system_r:xdm_t:s0-s0:c0.c1023 system_u:object_r:rpm_exec_t:s0
/bin/rpm [ file ] rpm-4.4.2.2-3.fc8 [target] selinux-policy-3.0.8-44.fc8
True targeted True Enforcing plugins.catchall_file Home-Net Linux
Home-Net 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:55:12 EDT 2007 i686 i686
13 Wed 06 Feb 2008 01:50:35 PM EST Thu 07 Feb 2008 10:26:00 AM EST
845ddb2e-69a4-6f67-5508-83456c0bff19
Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown>
(home_root_t). Detailed Description SELinux denied access requested by
sh. It is not expected that this access is required by sh and this
access may signal an intrusion attempt. It is also possible that the
specific version or configuration of the application is causing it to
require additional access. Allowing Access Sometimes labeling problems
can cause SELinux denials. You could try to restore the default system
file context for <Unknown>, restorecon -v <Unknown> If this does not
work, there is currently no automatic way to allow this access. Instead,
you can generate a local policy module to allow this access - see
http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
disable SELinux protection altogether. Disabling SELinux protection is
not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information Source Context Target Context Target Objects
Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search
} for comm=sh dev=sda7 egid=0 euid=0 exe=/bin/bash exit=-13 fsgid=0
fsuid=0 gid=0 items=0 name=home pid=4986
scontext=system_u:system_r:loadkeys_t:s0 sgid=0
subj=system_u:system_r:loadkeys_t:s0 suid=0 tclass=dir
tcontext=system_u:object_r:home_root_t:s0 tty=(none) uid=0
system_u:system_r:loadkeys_t:s0 system_u:object_r:home_root_t:s0 None [
dir ] selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
Oct 30 13:55:12 EDT 2007 i686 i686 2 Wed 06 Feb 2008 04:52:48 PM EST Wed
06 Feb 2008 04:52:48 PM EST 54a23c38-b925-4467-aa0e-5d3fdcc5d799
Summary SELinux is preventing sh (loadkeys_t) "search" to <Unknown>
(unconfined_home_dir_t). Detailed Description SELinux denied access
requested by sh. It is not expected that this access is required by sh
and this access may signal an intrusion attempt. It is also possible
that the specific version or configuration of the application is causing
it to require additional access. Allowing Access Sometimes labeling
problems can cause SELinux denials. You could try to restore the default
system file context for <Unknown>, restorecon -v <Unknown> If this does
not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access -
see http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385 Or you can
disable SELinux protection altogether. Disabling SELinux protection is
not recommended. Please file a
http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this package.
Additional Information Source Context Target Context Target Objects
Affected RPM Packages Policy RPM Selinux Enabled Policy Type MLS Enabled
Enforcing Mode Plugin Name Host Name Platform Alert Count First Seen
Last Seen Local ID Line Numbers Raw Audit Messages avc: denied { search
} for comm=sh dev=sda7 name=terry pid=4986
scontext=system_u:system_r:loadkeys_t:s0 tclass=dir
tcontext=unconfined_u:object_r:unconfined_home_dir_t:s0
system_u:system_r:loadkeys_t:s0
unconfined_u:object_r:unconfined_home_dir_t:s0 None [ dir ]
selinux-policy-3.0.8-44.fc8 True targeted True Enforcing
plugins.catchall_file Home-Net Linux Home-Net 2.6.23.1-42.fc8 #1 SMP Tue
Oct 30 13:55:12 EDT 2007 i686 i686 22 Wed 06 Feb 2008 04:52:48 PM EST
Wed 06 Feb 2008 04:52:48 PM EST 04bec695-038f-408d-bf7a-fa3c5f6e2812
~~R
