Yesterday I introduced SELinux and explained how to begin using it in 'Permissive' mode without affecting any existing processes on a server. Today I'm going to cover how to interpret a violation in the logs and how to find more information which might help to resolve the issue and allow you to run in 'Enforcing' mode. Enforcing mode is where the real security comes into play and mandatory access controls are enforced.
As I showed in my previous post, a violation will show up in /var/log/messages like the following:
Dec 26 07:30:26 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (ftp). For complete SELinux messages. run sealert -l 0621a8c3-b182-49cf-9116-c78a9dd52199
This message indicates that when executing 'vipw' it does not get access to my personalized vi config file (.exrc). This warning is valid since no system process should be accessing a file not labeled as a system file. To determine the context of a file, use the '-Z' flag with ls:
$ ls -Z ~/.exrc
-rw-r--r-- josh josh user_u:object_r:user_home_t /home/josh/.exrc
You can see the context is 'user_u:object_r:user_home_t'. This is clearly not a system file and that is why SELinux is preventing vipw from accessing it. To see more information about this error, run the 'sealert' command above:
sealert -l 0621a8c3-b182-49cf-9116-c78a9dd52199
Now, to include only the relevant portions, see the following:
Detailed Description
SELinux has denied /bin/vi access to potentially mislabeled file(s) (ftp).
This means that SELinux will not allow /bin/vi 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 system directories. The problem is that the
files end up with the wrong file context which confined applications are not
allowed to access.
Allowing Access
If you want /bin/vi to access this files, you need to relabel them using
restorecon -v ftp. You might want to relabel the entire directory using
restorecon -R -v .
Additional Information
Source Context user_u:system_r:sysadm_passwd_t
Target Context user_u:object_r:user_home_t
Target Objects ftp [ dir ]
Affected RPM Packages vim-minimal-7.1.12-1.fc7 [application]
Policy RPM selinux-policy-2.6.4-46.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Permissive
You can see from the above message that the process trying to access the file has a security context of 'user_u:system_r:sysadm_passwd_t' and it's fairly evident from this context that it's a system process related to authentication. Further up in the description you see the details of the violation and why it would refuse access.
If the file would have been a valid file for this process to access, and I wanted to grant that access, I could do so with the 'chcon' command:
chcon user_u:system_r:sysadm_passwd_t ~/.exrc
$ ls -Z !$
ls -Z ~/.exrc
-rw-r--r-- josh josh user_u:system_r:sysadm_passwd_t /home/josh/.exrc
This action would have failed if SELinux was in enforcing mode since it would not make sense to assign a sysadm_passwd_t context to a file in this location. This is a great example of how SELinux helps to keep your system secure without letting you mis-label files! This example also show how SELinux prevents mis-steps while giving you the opportunity to troubleshoot and find out what the real problem is.
Another great SELinux resource is the Unofficial SELinux FAQ.
Thursday, December 27, 2007
Wednesday, December 26, 2007
SELinux for all?
I recently migrated my mail server from a Gentoo Linux host to a Fedora 7 host and decided to use SELinux to improve my security posture. This is a big deal and should provide a greater level of security for my mail server, provided I can configure the security policies correctly.
SELinux was developed with the NSA and released under the GPL to provide a method of Mandatory Access Control for Linux.
The great benefit of using SELinux is that processes are prevented from accessing files that are not defined as belonging to, or associated with that process. This is a great thing! If a daemon or process were to be compromised, it would be restricted to the specific files and resources configured in the SELinux policy. Any violations are logged by the setroubleshoot daemon in the /var/log/messages syslog file and allow the user to review in order to allow or continue denial of the access attempt(s).
Enabling SELinux is very simple upon installation of Fedora or Red Hat Linux and is prompted during install. I do not recommend enabling on an OS that is in production and would only recommend enabling SELinux on a recent install or non-production host until you are very comfortable with it and have tuned your policies according to your production operation.
To get your feet wet, enable SELinux in permissive mode. This mode will allow all processes to run as if SELinux were off, but it will log any violations via auditd in syslog to allow you to tune your policies. You are prompted for this method upon install, or post-install, you could configure this via the following method:
1. use the setenforce command: setenforce permissive
usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
2. edit the /etc/selinux/config file:
SELINUX=permissive
Also, be sure to remove any mention of selinux from the /boot/grub/grub.conf file if you enable SELinux, or provide the proper flags to enable it. This is also the best way to disable SELinux if you are so inclined. An example would be:
#/boot/grub/grub.conf
title Fedora 7 (2.6.22.1-41.fc7)
root (hd0,0)
kernel /vmlinuz-2.6.22.1-41.fc7 ro root=/dev/vg01/f7_root rhgb quiet selinux=0
initrd /initrd-2.6.22.1-41.fc7.img
Note that on the kernel line I have passed 'selinux=0' to the kernel which would then disable this feature.
After enabling SELinux, check syslog frequently (/var/log/messages) to look for policy violations and tune your system. A typical policy violation would look like the following:
Dec 26 08:12:50 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (.exrc). For complete SELinux messages. run sealert -l 27ae2a46-19bb-47a8-b127-068a587e9494
In the above log entry, I used 'vipw' to access the /etc/passwd file and SELinux did not allow the 'vipw' binary to access my '.exrc' file (user customized file for VIM settings).
In short, SELinux can provide a GREAT measure of security to a seasoned administrator who is willing to take the time to learn how to use it. Use permissive mode and tune the policies to fit your particular environment. I do not know of anybody who uses SELinux in production or in a business due to the issues it seems to cause by lack of training and/or expertise in the configuration phase. Remember to disable SELinux and re-create the issue before bothering the application maintainer about any issues you may have.
SELinux was developed with the NSA and released under the GPL to provide a method of Mandatory Access Control for Linux.
The great benefit of using SELinux is that processes are prevented from accessing files that are not defined as belonging to, or associated with that process. This is a great thing! If a daemon or process were to be compromised, it would be restricted to the specific files and resources configured in the SELinux policy. Any violations are logged by the setroubleshoot daemon in the /var/log/messages syslog file and allow the user to review in order to allow or continue denial of the access attempt(s).
Enabling SELinux is very simple upon installation of Fedora or Red Hat Linux and is prompted during install. I do not recommend enabling on an OS that is in production and would only recommend enabling SELinux on a recent install or non-production host until you are very comfortable with it and have tuned your policies according to your production operation.
To get your feet wet, enable SELinux in permissive mode. This mode will allow all processes to run as if SELinux were off, but it will log any violations via auditd in syslog to allow you to tune your policies. You are prompted for this method upon install, or post-install, you could configure this via the following method:
1. use the setenforce command: setenforce permissive
usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
2. edit the /etc/selinux/config file:
SELINUX=permissive
Also, be sure to remove any mention of selinux from the /boot/grub/grub.conf file if you enable SELinux, or provide the proper flags to enable it. This is also the best way to disable SELinux if you are so inclined. An example would be:
#/boot/grub/grub.conf
title Fedora 7 (2.6.22.1-41.fc7)
root (hd0,0)
kernel /vmlinuz-2.6.22.1-41.fc7 ro root=/dev/vg01/f7_root rhgb quiet selinux=0
initrd /initrd-2.6.22.1-41.fc7.img
Note that on the kernel line I have passed 'selinux=0' to the kernel which would then disable this feature.
After enabling SELinux, check syslog frequently (/var/log/messages) to look for policy violations and tune your system. A typical policy violation would look like the following:
Dec 26 08:12:50 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (.exrc). For complete SELinux messages. run sealert -l 27ae2a46-19bb-47a8-b127-068a587e9494
In the above log entry, I used 'vipw' to access the /etc/passwd file and SELinux did not allow the 'vipw' binary to access my '.exrc' file (user customized file for VIM settings).
In short, SELinux can provide a GREAT measure of security to a seasoned administrator who is willing to take the time to learn how to use it. Use permissive mode and tune the policies to fit your particular environment. I do not know of anybody who uses SELinux in production or in a business due to the issues it seems to cause by lack of training and/or expertise in the configuration phase. Remember to disable SELinux and re-create the issue before bothering the application maintainer about any issues you may have.
Subscribe to:
Posts (Atom)