SELinux network connection issue
I've installed a live version of Fedora 10 which also has SELinux installed on it. After I log in and try and connect to the network I receive an error stating
Quote:
Any suggestions on how to fix it? =================================== Edit: Simply putting SELinux in permissive mode is not what I am looking for. It's my understanding that SELinux is a good security measure. I should also state that the message is less of an error and more of a warning or explanation. |
I can't be the only one with this issue. It's literally a fresh install. I know my network card is working I had a non-live version of FC10 on just a few hours ago and it was working fine.
I notice also that during boot there are some issues starting NFS ...statd..... RPC IDMAP... I can post more on that if you think its helpful. If I can't get this to work than I feel like either SELinux is way more trouble than its worth... which is a shame considering the amount of work that has gone into it, or I have a peculiar setup compared to other people. |
type setenforce 0 and that will put the policy in a passive mode. I don't know if you can update the policy if it is a live version of fc10
Also Please be patient for people to respond. I have noticed that there are few regulars that are familiar with SELinux on the forums. SELinux can be a handful edit: sorry didnt see your edit |
Quote:
Code:
getsebool -a |grep -i network Code:
getsebool -a |grep -i tcp |
are you running it live off a cd or from an install?
getsebool is a good way to check but can be useless if your selinux booleans file is empty(like mine). Since the booleans file is not required for the system to work you can blank the booleans file and just let the policy decide what is and is not allowed. (this will only work if you have a modular policy, if you have a monolithc policy then set booleans is the way to go) if it is installed and not a live cd put the system into permissive mode with setenforce then then cd to a tmp dir. like /tmp run audit2allow -a -l -m netmanager that will create a module for selinux to use ( as long as you have a modular policy and not a monolithic policy) then in the same directory run semodule -i netmanager.pp ( i think it is .pp there are 3 files that audit2allow creates but it will only allow one to work with semodule) |
I installed FC10 off of a live version disc. So in other words it is booting off of the hard drive. I Should also point out that the network was working fine when I had booted the live version off of the disc.
I'll get that output of that command right away. |
Quote:
-C |
Here's the output:
Quote:
|
Quote:
Post the output of: Code:
getsebool -a |
Sorry so long:
Code:
# getsebool -a |
Quote:
Code:
root@host# restorecon -v 'libdbus-glib-1.so.2' OR If you don't know where it is do the following... Code:
root@host# touch /.autorelabel Code:
root@host# chcon -t dhcpc_t libdbus-glib-1.so.2 -C |
That appears to have worked. Thank you very much.
Now any sort of explanation? I have only recently started reading up on SELinux. I haven't found too much for resources that contain practical examples. My basic understanding is that the context was somehow incorrect. Perhaps it was confined in some way? I wonder what the issue is in going from the live [off disc] version, to the installed on hard drive version. Here is what the context is now: Code:
# ls -la --lcontext /usr/lib/libdbus-glib-1.so.2 |
Quote:
Basically DHCP was trying to access libdbus-glib-1.so.2.1.0 and SELinux didn't like that (for whatever reason...I'm pretty sure the logs will tell you specifically why). Also note that SELinux acts "funny" with symbolic links. So you just have to watch the logs and turn on the SELinux troubleshooter. -C |
Running "chcon -t dhcpc_t libdbus-glib-1.so.2" would not have been a good thing to do. Sure it alleviates things but that would be like treating symptoms instead of addressing the cause. Recall that SELinux by default does not allow any access (and that includes root AFAIK) and that it's only rules that shape access, transitions, et cetera. So if a process with context "dhcpc_t" is not allowed to access a resource with context "usr_t" (see /etc/selinux/${POLICY}/contexts/files/file_contexts) then you get a denial. So restoring the context on the library was a Good first Thing to do in terms of troubleshooting. Not that I know anything about SELinux of course.
|
All times are GMT -5. The time now is 10:06 AM. |