danwalsh (![[info]](http://p-stat.livejournal.com/img/userinfo.gif){kind=small} danwalsh) wrote,@ 2006-08-09 15:33:00 |
|
One of the great strengths of SELinux and other MAC architectures is that applications do not have to be modified to be protected by SELinux. This allows us to write policy for a great many services without going through the process of modifying code and getting upstream acceptance. It also allows flexibility in that different vendors or different users can have different security profiles for an application without having to modify the application.
While this is a great benefit to the developers it is not necessarily a great benefit to usability. Since applications do not understand what SELinux is doing, they can not report that SELinux is preventing them from doing something. As an example if you are running an Apache Web Server and SELinux denies access to a file, the apache web server reports permission denied. Users of Unix and other operating systems have gained experience through the years, understand that permission denied means that there is a problem with either the files ownership or file permissions (DAC). But when they go look at the file they see that apache has ownership and can read it. This leads them to scratching their heads. They go back to the log file and all it says is permission denied.
Some may suspect that SELinux is the problem, but how do they tell? If they figure that SELinux is causing the denial, how do they fix it? Could this be a security violation attempt? Could this be a configuration problem? Is the file mislabeled?
We have created a new tool in FC6 and RHEL5 called the SELinux Troubleshooter. (setroubleshoot). This tool watches the
audit log files for AVC messages. When an AVC messages arrives the tool runs through the SELinux plugins database
looking for a match and then sends a message to the user with a description, and a suggested fix.
As an example, say you create a file index.html in your homedir and mv it to /var/html/www directory. If you try to access this file via a web browser you will receive an avc message that looks like:
type=AVC msg=audit(1155056960.933:208967): avc: denied { getattr } for pid=12321 comm="httpd" name="index.html" dev=dm-0 ino=6260297 scontext=user_u:system_r:httpd_t:s0-s0:c
Obviously this tells you that apache web server is not allowed to look at files labeled with the users home directory label.:^)
With setroubleshoot you receive a message like the following:
You can also configure the setroubleshoot daemon to send mail when it receives an AVC. So you will get them even on servers or when
not logged in.
There are currently 56 Plugins which map to all of the booleans along with several known situations that come up. There is also
a catchall plugin (disable_trans) which will look for avc's with no match and will suggest either writing a loadable policy module or
disable trans.
You can read more about this tool at
http://fedoraproject.org/wiki/SELinux/se
The Plugin code to generate the above message is fairly simple and looks like this:
from setroubleshoot.util import *
from setroubleshoot.Plugin import Plugin
from rhpl.translate import _
import re
class plugin(Plugin):
summary =_('''
SELinux is preventing the http daemon from using potentially mislabeled files ($
TARGET_PATH).
''')
problem_description = _('''
SELinux has denied the http daemon access to potentially
mislabeled files ($TARGET_PATH). This means that SELinux will not
allow http to use these files. It is common for users to edit
files in their home directory or tmp directories and then move
(mv) them to the httpd directory tree. The problem is that they
end up with a file context which http is not allowed to access.
''')
fix_description = _('''
If you want the http daemon to access this files, you need to
relabel them using restorecon if they are under the standard
httpdirectory tree, or use chcon -t http_sys_content_t. You can
look at the httpd_selinux man page for addtional information.
''')
def __init__(self):
Plugin.__init__(self,__name__)
def analyze(self):
if self.avc.sourceTypeMatch("httpd_t httpd_sys_script_t httpd_user_script_t
httpd_staff_script_t") and \
self.avc.targetTypeMatch("user_home_t staff_home_t user_tmp_t staff_t
mp_t tmp_t"):
return True
return False
Now if you are interested in helping in this effort. We could use help:
* proof reading thes plugins. They are in /usr/share/setroubleshoot/plugins directory.
* If you have ideas about additional plugins, bring them up on the fedora-selinux list. Patches Welcome.
* Testing.
This tool is a work in progress.
There are some gotchas in this tool and it has been known to go into an infinite loop. Usually when it reports bugs about itself.
While this is a great benefit to the developers it is not necessarily a great benefit to usability. Since applications do not understand what SELinux is doing, they can not report that SELinux is preventing them from doing something. As an example if you are running an Apache Web Server and SELinux denies access to a file, the apache web server reports permission denied. Users of Unix and other operating systems have gained experience through the years, understand that permission denied means that there is a problem with either the files ownership or file permissions (DAC). But when they go look at the file they see that apache has ownership and can read it. This leads them to scratching their heads. They go back to the log file and all it says is permission denied.
Some may suspect that SELinux is the problem, but how do they tell? If they figure that SELinux is causing the denial, how do they fix it? Could this be a security violation attempt? Could this be a configuration problem? Is the file mislabeled?
We have created a new tool in FC6 and RHEL5 called the SELinux Troubleshooter. (setroubleshoot). This tool watches the
audit log files for AVC messages. When an AVC messages arrives the tool runs through the SELinux plugins database
looking for a match and then sends a message to the user with a description, and a suggested fix.
As an example, say you create a file index.html in your homedir and mv it to /var/html/www directory. If you try to access this file via a web browser you will receive an avc message that looks like:
type=AVC msg=audit(1155056960.933:208967): avc: denied { getattr } for pid=12321 comm="httpd" name="index.html" dev=dm-0 ino=6260297 scontext=user_u:system_r:httpd_t:s0-s0:c
Obviously this tells you that apache web server is not allowed to look at files labeled with the users home directory label.:^)
With setroubleshoot you receive a message like the following:
You can also configure the setroubleshoot daemon to send mail when it receives an AVC. So you will get them even on servers or when
not logged in.
There are currently 56 Plugins which map to all of the booleans along with several known situations that come up. There is also
a catchall plugin (disable_trans) which will look for avc's with no match and will suggest either writing a loadable policy module or
disable trans.
You can read more about this tool at
http://fedoraproject.org/wiki/SELinux/se
The Plugin code to generate the above message is fairly simple and looks like this:
from setroubleshoot.util import *
from setroubleshoot.Plugin import Plugin
from rhpl.translate import _
import re
class plugin(Plugin):
summary =_('''
SELinux is preventing the http daemon from using potentially mislabeled files ($
TARGET_PATH).
''')
problem_description = _('''
SELinux has denied the http daemon access to potentially
mislabeled files ($TARGET_PATH). This means that SELinux will not
allow http to use these files. It is common for users to edit
files in their home directory or tmp directories and then move
(mv) them to the httpd directory tree. The problem is that they
end up with a file context which http is not allowed to access.
''')
fix_description = _('''
If you want the http daemon to access this files, you need to
relabel them using restorecon if they are under the standard
httpdirectory tree, or use chcon -t http_sys_content_t. You can
look at the httpd_selinux man page for addtional information.
''')
def __init__(self):
Plugin.__init__(self,__name__)
def analyze(self):
if self.avc.sourceTypeMatch("httpd_t httpd_sys_script_t httpd_user_script_t
httpd_staff_script_t") and \
self.avc.targetTypeMatch("user_home_t staff_home_t user_tmp_t staff_t
mp_t tmp_t"):
return True
return False
Now if you are interested in helping in this effort. We could use help:
* proof reading thes plugins. They are in /usr/share/setroubleshoot/plugins directory.
* If you have ideas about additional plugins, bring them up on the fedora-selinux list. Patches Welcome.
* Testing.
This tool is a work in progress.
There are some gotchas in this tool and it has been known to go into an infinite loop. Usually when it reports bugs about itself.
