PDA

View Full Version : SELinux is a major pain in the ***. Please, help.



MarkE
14th September 2006, 12:05 AM
I do not wish to disable SELinux, but every single time it blocks some kind of action, the program that I am trying to execute simply outputs or logs that the command couldn't be completed or permission was denied, and nothing more. Let me tell you two examples:
1) I tried for days to get a single Apache HTTP SSI (Server-Side Includes) script to run an exec command for a single executable, but it never could. The httpd_selinux man page never even mentioned a single thing about the httpd_ssi_exec boolean variable for SELinux, but that is what I had to set. Using the command getsebool gave me a list of booleans in which httpd_ssi_exec was listed, but that isn't good enough.
2) I was unable to run RPM because it constantly could not access its database files. I found, by accident, that it should have had the rpm_var_lib_t SELinux context.

In both of these situations, there was absolutely no indication whatsoever by the programs, the programs' logs, or the system log (/var/log/messages) that SELinux had caused the problem. What I need is a concrete log or some way of finding out exactly what SELinux protection was invoked, what context the file it was trying to access SHOULD have been set to, etc. so that I can easily correct the problem myself.

Does anyone have any experience with SELinux? If so, could you please tell me how you figure out when and why SELinux blocks a certain action, or at least post if you experience similar headaches with it?

Thanks

RahulSundaram
14th September 2006, 12:41 AM
I do not wish to disable SELinux, but every single time it blocks some kind of action, the program that I am trying to execute simply outputs or logs that the command couldn't be completed or permission was denied, and nothing more. Let me tell you two examples:
1) I tried for days to get a single Apache HTTP SSI (Server-Side Includes) script to run an exec command for a single executable, but it never could. The httpd_selinux man page never even mentioned a single thing about the httpd_ssi_exec boolean variable for SELinux, but that is what I had to set. Using the command getsebool gave me a list of booleans in which httpd_ssi_exec was listed, but that isn't good enough.
2) I was unable to run RPM because it constantly could not access its database files. I found, by accident, that it should have had the rpm_var_lib_t SELinux context.

In both of these situations, there was absolutely no indication whatsoever by the programs, the programs' logs, or the system log (/var/log/messages) that SELinux had caused the problem. What I need is a concrete log or some way of finding out exactly what SELinux protection was invoked, what context the file it was trying to access SHOULD have been set to, etc. so that I can easily correct the problem myself.

Does anyone have any experience with SELinux? If so, could you please tell me how you figure out when and why SELinux blocks a certain action, or at least post if you experience similar headaches with it?

Thanks

There is a trouble shooting section in http://fedoraproject.org/wiki/SELinux which is generally helpful on the usual methods.

There is also work being done on making access denials more clear at http://fedoraproject.org/wiki/SELinux/setroubleshoot
http://danwalsh.livejournal.com/7212.html

MarkE
14th September 2006, 04:15 AM
Thanks,
I guess the clandestine SELinux denials are a widespread problem for which no one has found a solution yet. :rolleyes:

Suppose, though, that I know which file is being denied from being accessed by which program (say, rpm trying to access its database files), and let's say the SELinux manpage for that program either doesn't exist or isn't specific about what context that file should have. Is there any technical means by which I can find the security context under which a program runs and which file contexts it is restricted to accessing? For example, how would I find out the name rpm_var_lib_t if I had absolutely no idea what context the folder /var/lib/rpm is supposed to have? For any program p trying to access any file f, how do I find out what context(s) c[] that f must have in order for p to be able to access it?

SlowJet
14th September 2006, 07:06 AM
Zarro Boogs found.

on redhat bugzilla for httpd or selinux-policy or selinux-policy-targetedconcerning this for
FC5test1,2,3,final or FC6test1,2,3 or devl

Have you filed a bug or tested it before lately?

The same thing happen with nfs, in that months after the fist guy using it with new features shows up.
You may be the fisrt guy to use and report ssl sever side includes on httpd with selinux enabled.

SJ

timdsmith
14th September 2006, 11:40 AM
Thanks,
I guess the clandestine SELinux denials are a widespread problem for which no one has found a solution yet. :rolleyes:I found a solution...Disabled it. :D

David Becker
14th September 2006, 11:56 AM
I found a solution...Disabled it. :D

Kill the patient!

Maybe audit2allow can provide a solution for the issues here?

David

David Becker
14th September 2006, 12:11 PM
I do not wish to disable SELinux, but every single time it blocks some kind of action, the program that I am trying to execute simply outputs or logs that the command couldn't be completed or permission was denied, and nothing more. Let me tell you two examples:
1) I tried for days to get a single Apache HTTP SSI (Server-Side Includes) script to run an exec command for a single executable, but it never could. The httpd_selinux man page never even mentioned a single thing about the httpd_ssi_exec boolean variable for SELinux, but that is what I had to set. Using the command getsebool gave me a list of booleans in which httpd_ssi_exec was listed, but that isn't good enough.
2) I was unable to run RPM because it constantly could not access its database files. I found, by accident, that it should have had the rpm_var_lib_t SELinux context.

In both of these situations, there was absolutely no indication whatsoever by the programs, the programs' logs, or the system log (/var/log/messages) that SELinux had caused the problem.

I'm wondering why this isn't being logged. Is your system running 'kauditd' ?

David

MarkE
14th September 2006, 09:53 PM
Thanks for responses,
1.) I don't believe this is a bug, it's just a hardship and user-unfriendliness. The only bug regarding SSI with HTTPD is, if you take one look at the manpage entitled httpd_selinux, it will list most things relating to scripts and executions by httpd, but it mentions nothing of the sebool httpd_ssi_exec that I found out needs to be enabled to use the SSI <!--#exec ...--> command. As for the problem of my rpm database not being labeled correctly (which was an accident), there is no manpage like rpm_selinux.

2.) Here is another problem I have with SELinux. At first, I knew how to read file contexts with ls -Z, but when something was the wrong context, I had no idea how to change it. I eventually found out it is the chcon command. But if you read the main selinux manpage, it doesn't provide any cross-reference for the chcon command (which is a basic necessity). It only tells you about restorecon, which is only for fixing errors, and even that manpage doesn't cross-reference you to anything helpful. I also was just browsing in /etc/selinux (which has files that list selinux contexts, which might provide some help) and I found setrans.conf, which says to use the semanage command. This is also an important tool in managing SELinux policies, yet again, it isn't cross-referenced by the main page! The problem is that whenever I need to do a certain thing with SELinux, I always have to browse on the Internet to find the info because the da*n SELinux manpage doesn't give you the information you need! It is very difficult to get information about SELinux commands unless you already know the name of the command, because the SELinux manpages don't provide any association or cross-reference to each other. The SELinux manpage should talk about file contexts AND tell you that the command to change them is chcon.

Basically, what I am trying to say in so many words, is that the documentation of SELinux as a whole, as well as SELinux program-specific implementations (such as httpd), is terrible, insufficient, inadequate, disconnected, disorganized, arcane, user-unfriendly, and just plain poopy.

3.) As for disabling SELinux, I suppose when I am no longer able to find a solution, it might come to that. What's the point of having the best security if it prevents you from living your life?

4.) I tried the following command: yum info kaudit kauditd audit2allow
Nothing came up. How do I get these programs? What are they for? How do I use them?

5.) In /etc/selinux, I can find files saying what programs have what contexts and what directories should have what contexts, but I can't find the policy that says whether a program with context pc can access a file with context fc.

6.) I have a problem that I think SELinux is causing for itself. When I run setsebool, I get this garbage, but it sets the sebool anyway:

[root@localhost sbin]# ./setsebool httpd_ssi_exec 1
Traceback (most recent call last):
File "/usr/sbin/genhomedircon", line 28, in ?
from semanage import *;
File "/usr/lib64/python2.4/site-packages/semanage.py", line 5, in ?
import _semanage
ImportError: /lib64/libsemanage.so.1: undefined symbol: sepol_policydb_mls_enabl
ed
libsemanage.semanage_install_sandbox: genhomedircon returned error code 1.

I've been ignoring the problem, but now, semanage fails all the time with a similar error:

[root@localhost sbin]# ./semanage
Traceback (most recent call last):
File "./semanage", line 24, in ?
import seobject
File "/usr/lib64/python2.4/site-packages/seobject.py", line 25, in ?
from semanage import *;
File "/usr/lib64/python2.4/site-packages/semanage.py", line 5, in ?
import _semanage
ImportError: /lib64/libsemanage.so.1: undefined symbol: sepol_policydb_mls_enabl
ed

Thanks for help

MarkE
14th September 2006, 10:13 PM
I fixed the last stated problem by doing yum install libsepol. But please still regard previous 5 issues.

MarkE
14th September 2006, 11:28 PM
Okay, I did something no user should ever have to do. I went to /usr/share/man and went into each of the man* (1-9) directories and ran the command:
[root@localhost mark]# for f in `ls *`; do gunzip -c -d $f | grep -i selinux --files-with-match --label=$f; done to obtain a full enumeration of all the gzipped manpages with the word "selinux" in them. This is the extent I had to go to, and them some.

You know what? I'll bet you that there are more SELinux commands WITHOUT manpages in directories other than /bin, /sbin, /usr/bin, and /usr/sbin -- commands surreptitiously hidden in obscure, undisclosed directories so that we users will NEVER find them, despite the fact that such commands are necessary to make SELinux configurable!!!
>}:-(

David Becker
15th September 2006, 12:10 AM
4.) I tried the following command: yum info kaudit kauditd audit2allow
Nothing came up. How do I get these programs? What are they for? How do I use them?


It's not a package, rather a kernel thread that should format/log audit messages. The question is whether it's running or rather why you aren't receiving audit messages.

David

David Becker
15th September 2006, 12:27 AM
audit2allow
Nothing came up. How do I get these programs? What are they for? How do I use them?


Comes with policycoreutils package. Read the manual page.

But I'd first find out why you're not receiving audit messages when SELinux is apparently in your way.

David

MarkE
15th September 2006, 03:26 AM
If you're talking about the AVC denied messages in /var/log/messages, I get those, but they are quite unhelpful messages.

David Becker
15th September 2006, 09:58 AM
If you're talking about the AVC denied messages in /var/log/messages, I get those, but they are quite unhelpful messages.

They can be helpful for audit2allow.

From the man page of audit2allow:


audit2allow - generate policy allow rules from logs of denied operations

Lookup the manual page before you install otherwise.

David

MarkE
16th September 2006, 05:00 PM
1.) I have audit2allow. What file should I use it on? (It seems to work on dmesg and on /var/log/messages.)
2.) I opened the policycoreutils rpm package, like you said, and found most of the SELinux commands in there. I didn't find chcon. (What package does that come in?) But I did find something that totally makes me boil: the audit2why command. (Take a look in the package and you'll see it.) So I already have this command installed, and guess what its manpage says? Guess what?!


audit2why - Translates SELinux audit messages into a description of why
the access was denied

SYNOPSIS
audit2why [options]

OPTIONS
--help Print a short usage message

-p <policyfile>
Specify an alternate policy file.

DESCRIPTION
This utility processes SELinux audit messages from standard input and
and reports which component of the policy caused each permission denial
based on the specified policy file if the -p option was used or the
active policy otherwise. There are three possible causes: 1) a missing
or disabled TE allow rule, 2) a constraint violation, or 3) a missing
role allow rule.

:mad: Can you f*** believe this?! This is probably the command I have needed all along, and not in one place, not one, does it tell you [I]anywhere[I] in the system!!! How can they do this? I would like very much to give a piece of my mind to the SELinux people who put all those policycoreutils programs into one package and didn't even provide any way to know about the programs once they are installed (especially the most important ones). Oh... wait a minute... I just found something in the audit2allow manpage... The only credit I [I]can[I] give them, however, is that if you look in the manpage of the first command you told me about (audit2allow), it mentions audit2why.

Okay... I vented my indignation. Can you please help me in using the audit2why command? It talks about SELinux audit files (which I wish I knew where they were, but they are probably hidden). Thanks for your help so far.

MarkE
16th September 2006, 05:07 PM
Okay, I looked further at the manpage for audit2why, and it says this:


EXAMPLE
$ /usr/sbin/audit2why < /var/log/audit/audit.log

I checked my /var/log/audit folder, and no file exists inside. How can I turn on SELinux auditing?

Firewing1
16th September 2006, 05:15 PM
SELinux audits are in /var/log/messages.
-- side note --
I always disable SELinux, and gave it another trial. Failed horribly. I couldn't run my web or samba server, among other things. I figured out a way to make a custom policy module, and if you look at my list of howto's I show you the process of how I did it. Basically it takes an error message, converts it into a SELinux rule, and 'allows' that rule. But the messages never stopped, so I just disabled it in the end.
-- end side note --
Firewing1