Showing posts with label SELinux. Show all posts
Showing posts with label SELinux. Show all posts

Sunday, September 11, 2011

Apache and SELinux

SkyHi @ Sunday, September 11, 2011
Server Training - Web Server

SELinux with Apache

Security with Apache is an important topic, of which SELinux is a part. However, the frustration that results in trying to manage SELinux and how it relates to an Apache Web Server is huge. Most of the time, administrators bail and shut down SELinux because they do not have the time to correctly configure the system. SELinux can be a key to good security for the Apache daemon. This tutorial with help you develop several skills that will provide some level of SELinux management for the Apache Web Server.

View Processes protected by SELinuxYou may view processes which are restricted by SELinux with ps. While your Apache Web Server is running you can view the processes under management. Remember that by default Apache will start 8 web servers when it is initialized so that is why you see this number of processes running. The ps command had to be completely rewritten to provide these SELinux attributes.
# ps -ZC httpd
LABEL PID TTY TIME CMD
root:system_r:httpd_t 11759 ? 00:00:00 httpd
root:system_r:httpd_t 15899 ? 00:00:00 httpd
root:system_r:httpd_t 15900 ? 00:00:00 httpd
root:system_r:httpd_t 15901 ? 00:00:00 httpd
root:system_r:httpd_t 15902 ? 00:00:00 httpd
root:system_r:httpd_t 15903 ? 00:00:00 httpd
root:system_r:httpd_t 15918 ? 00:00:00 httpd
root:system_r:httpd_t 15919 ? 00:00:00 httpd
root:system_r:httpd_t 15920 ? 00:00:00 httpd
If you wanted to view the entire list of processes currently protected with SELinux you would use this command:

# ps -eZ
LABEL PID TTY TIME CMD
system_u:system_r:init_t 1 ? 00:00:00 init
system_u:system_r:kernel_t 2 ? 00:00:00 migration/0
system_u:system_r:kernel_t 3 ? 00:00:00 ksoftirqd/0
system_u:system_r:kernel_t 4 ? 00:00:00 watchdog/0
system_u:system_r:kernel_t 5 ? 00:00:00 events/0
system_u:system_r:kernel_t 6 ? 00:00:00 khelper
system_u:system_r:kernel_t 7 ? 00:00:00 kthread
system_u:system_r:kernel_t 10 ? 00:00:00 kblockd/0
system_u:system_r:kernel_t 11 ? 00:00:00 kacpid
---cut---


SELinux sees everything as an object. Access to objects are controlled by security elements stored in the inode, which now has extended fields. The security elements combined create a security context which consists of five elements.

user
The role is used to indicate the user of the context. If a user logs in as root they will have a user value of root. If they log in as a regular user, like tom, they will have the value of user_u. Users who su to root will continue to have the value of user_u. Processes also have a value, system_u.
role
This is used to define the role of the user. Files have a role of object_r and processes have a role of system_r. Users, like processes have the role of system_r.
type
Types are used to create a type enforcement which determines which process types can have access to which file types.
sensitivity
This is a security feature used by government agencies.
category
This provides a way to block access to categories of people including root.
user: role: type: sensitivity: category
If you view the settings for the index.html file in /var/www/html you will see these attributes listed.
# ls -Z
-rw-r--r-- root root root:object_r:httpd_sys_content_t index.html
user: root:
role: object_r:
type: httpd_sys_content_t
sensitivity:
category
It is important to note that the type: httpd_sys_content_t is required in order to view a SELinux object such as index.html. This type serves up content whereas if you wanted to use a cgi program or any other active page you will need a different type. Listed below are various types and also how to manage those types so they work.
If you are going to use the apache web server you will need to know how to adjust the SELinux for that daemon. The first step in this process is to evaluate the booleans that are set for httpd in SELinux. Here is a list of the types that are available for the Apache Web Server.

# getsebool -a | grep httpd
allow_httpd_anon_write --> off
allow_httpd_mod_auth_pam --> off
allow_httpd_sys_script_anon_write --> off
httpd_builtin_scripting --> on
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_can_network_relay --> off
httpd_disable_trans --> off
httpd_enable_cgi --> on
httpd_enable_ftp_server --> off
httpd_enable_homedirs --> on
httpd_rotatelogs_disable_trans --> off
httpd_ssi_exec --> off
httpd_suexec_disable_trans --> off
httpd_tty_comm --> off
httpd_unified --> on

Here is a brief description of several major types.
httpd_sys_content_t
Set files with httpd_sys_content_t for content which is available from all httpd scripts and the daemon.
httpd_sys_script_exec_t
Set cgi scripts with httpd_sys_script_exec_t to allow them to run with access to all sys types.
httpd_sys_script_ro_t
Set files with httpd_sys_script_ro_t if you want httpd_sys_script_exec_t scripts to read the data, and disallow other sys scripts from access.
httpd_sys_script_rw_t
Set files with httpd_sys_script_rw_t if you want httpd_sys_script_exec_t scripts to read/write the data, and disallow other non sys scripts from access.
httpd_sys_script_ra_t
Set files with httpd_sys_script_ra_t if you want httpd_sys_script_exec_t scripts to read/append to the file, and disallow other non sys scripts from access.
httpd_unconfined_script_exec_t
Set cgi scripts with httpd_unconfined_script_exec_t to allow them to run without any SELinux pro-
tection. This should only be used for a very complex httpd scripts, after exhausting all other options. It is better to use this script rather than turning off SELinux protection for httpd.

SELinux policy is customizable based on least access required. So by default SElinux prevents certain http scripts from working. httpd policy is extremely flexible and has several booleans that allow you to manipulate the policy and run httpd with the tightest access possible. Here is the process for changed the status of these booleans for the Apache Web Server.

Enable cgi
If you wanted to enable the server to run cgi scripts you will need to change the boolean to allow this type. And...this is important...you will need to alter your cgi scripts so that their type is this type for cgi.
# setsebool -P httpd_enable_cgi 1
Now that you have enabled cgi you will need to change the type for your cgi applications. Type Enforcement is the primary method of security for the targeted policy. The Type can be changed using the chcon command. However, the chcon command can only change to a Type that is defined by the policy.


# ls -Z
-rw-r--r-- root root root:object_r:httpd_sys_content_t myprogram.cgi

In this example the cgi program will not be able to execute as it is a content type not the cgi type.

# chcon -t httpd_sys_script_exec_t myprogram.cgi

# ls -Z
-rw-r--r-- root root root:object_r:httpd_sys_script_exec_t myprogram.cgi
Now the cgi should be able to execute.

Enable User home Directories and Change Context
You may want to allow users to show web pages from their home directory.
# setsebool -P httpd_enable_homedirs 1
# chcon -R -t httpd_sys_content_t ~user/public_html

Enable Access to Terminal
httpd may need to prompt for a password on a certificate file
# setsebool -P httpd_tty_comm 1

Disable File Control Contexts
# setsebool -P httpd_unified 0

Disable PHP
You will need to manage the PHP settings for SELinux in order to run PHP.
# setsebool -P httpd_builtin_scripting 0

Enable Network Connections from httpd
Disabled to prevent hackers from attacking other machines from httpd.
# setsebool -P httpd_can_network_connect 1

Disable suexec Transition
# setsebool -P httpd_suexec_disable_trans 1

Disable Protection for httpd Daemon

# setsebool -P httpd_disable_trans 1
# service httpd restart

Changing a http Port
You may want to change a port number for http. You cannot do this without editing the configuration for SELinux.

# semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989

Change httpd to port 81 in the httpd.conf file.

Listen 81

Now restart, and you will see that it will fail to restart. Check /var/log/messages for output.

Dec 10 08:03:46 cent2 setroubleshoot: SELinux is preventing the /usr/sbin/httpd (httpd_t) from binding to port 81. For complete SELinux messages. run sealert -l 9d1872a0-da1f-48b3-b7bc-4ed7094387e5

In order to fix this you will need to use the semanage command to add port 81 to the ports allowed by SELinux.
# semanage port -a -t http_port_t -p tcp 81

Restart httpd and you will find that it works. Now verify that port 81 was added to the default allowed ports.

# semanage port -l | grep http
http_cache_port_t tcp 3128, 8080, 8118
http_cache_port_t udp 3130
http_port_t tcp 81, 80, 443, 488, 8008, 8009, 8443
pegasus_http_port_t tcp 5988
pegasus_https_port_t tcp 5989

Managing Context Problems
A common problem is when you create HTML pages in a user directory with the context of the user and then copy them to the http directories to be used as web pages. Here is an example. Mike build an index.html page to be moved into the root directory for httpd. The file is created in the user's home directory and as you can see it will have this context:

# ls -Z index.html
-rw-rw-r-- mike mike root:object_r:user_home_t index.html
That file is copied into /var/www/html as the main index page but still has the same context, at least in some scenarios if the user has rights in the directory.

# ls -Z /var/www/html
-rw-r--r-- root root root:object_r:httpd_sys_content_t index.html

Changing the Type
Type Enforcement is the primary method of security for the targeted policy. The Type can be changed using the chcon command. However, the chcon command can only change to a Type that is defined by the policy.


# ls -Z
-rw-r--r-- root root root:object_r:httpd_sys_content_t index.html

# chcon -t tmp_t index.html

# ls -Z
-rw-r--r-- root root root:object_r:tmp_t index.html

You may also want to use a reference file to change the Type using the chcon command. The idea is to locate a file with the correct settings and then use it as a reference to correct another file. The example shows that the index.html file is incorrect but that the test.htm file can be used as a reference to fix the index.html file.
# ls -Z
-rw-r--r-- root root root:object_r:tmp_t index.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm

# chcon --reference test.htm index.html

# ls -Z
-rw-r--r-- root root root:object_r:httpd_sys_content_t index.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm
Another way to correct the problem is to use restorecon. This command can be used to bring all files in a directory back to the required Type. In this example restorecon repairs the index.html file that would not work correctly. Be sure to put a “/*” at the end of the directory you want to fix.

# ls -Z
-rw-r--r-- root root root:object_r:tmp_t index.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm

# restorecon /var/www/html/*

# ls -Z
-rw-r--r-- root root system_u:object_r:httpd_sys_content_t index.html
-rw-r--r-- root root root:object_r:httpd_sys_content_t test.htm


REFERENCES

Saturday, September 10, 2011

RHEL6 and SElinux

SkyHi @ Saturday, September 10, 2011
One of the most important packages to run successfully RHEL6 and SElinux is the setroubleshoot package. It includes useful tools like the setroubleshoot daemon and utils like sealert, sestatus…..
So lets see whats the sestatus of my system:

[root@rhel1 ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted
Ok so assuming i want to set up an ftp server. I know my configuration is correct. Permissions on the directories are set etc… But ftp still do not let me write to the directory.  So i need to have a tool which shows me the audit.log of selinux. This can be done with sealert.

If you only have a console available and no X-Window System you can use the command
#sealert -a /var/log/audit/audit.log > myselinuxerrors.txt
or if you have gui

#sealert -b
Mostly you will find hints like
To let anonymous users write to a ftp directory set allow_ftpd_anon_write to 1
to do this just set
#setsebool -P allow_ftpd_anon_write=1

REFERENCES
http://www.salsaunited.net/blog/?p=48

RHEL6 SELinux cheat sheet

SkyHi @ Saturday, September 10, 2011
Lot of admin turn SELinux off because it looks complicated. Here is a cheat sheet to make your life easier
Two important documentations about Selinux can be found here:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Security-Enhanced_Linux/index.html
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/index.html
—————————————————————————–
If you work on Centos or Redhat, install the following packages on your system:
setroubleshoot.noarch : Helps troubleshoot SELinux problems
setroubleshoot-plugins.noarch : Analysis plugins for use with setroubleshoot
setroubleshoot-server.noarch : SELinux troubleshoot server


[root@client1 ~]# yum install setroubleshoot
Start the setroubleshootd daemon:


[root@client1 ~]#setroubleshootd
—————————————————————————–
Get the status of selinux:
[root@client1 ~]#sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 21
Policy from config file: targeted
Check for permissive or enforcing mode: 


[root@client1 ~]#getenforce
If you get back a 1 selinux is turned on if you get back a 0 its turned off.
Switch selinux modes from permissive to enforcing and back: 


[root@client1 ~]#setenforce 1 (will set enforcing mode)


[root@client1 ~]#setenforce 0 (will set permissive mode)
—————————————————————————–
Selinux AVC Log files:
All selinux logs can be found in /var/log/audit/audit.log
SELinux logfiles looks very crytpy without the tool sealert. Here an extract of the log without and with the command sealert:


[root@client1 ~]#less /var/log/audit/audit.log
type=DAEMON_START msg=audit(1304542876.396:4843): auditd start, ver=1.7.18 format=raw kernel=2.6.18-238.el5 auid=4294967295 pid=2553 subj=system_u:system_r:auditd_t:s0 res=success
type=CONFIG_CHANGE msg=audit(1304542876.570:4): audit_enabled=1 old=0 by auid=4294967295 subj=system_u:system_r:auditd_t:s0 res=1


[root@client1 ~]# sealert -a /var/log/audit/audit.log | less
found 1 alerts in /var/log/audit/audit.log
——————————————————————————–
Summary:
SELinux is preventing nagios (nagios_t) “getattr” to /var/nagios/objects.cache
(var_t).
Detailed Description:
[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]
SELinux denied access requested by nagios. It is not expected that this access
is required by nagios 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 /var/nagios/objects.cache,
restorecon -v ‘/var/nagios/objects.cache’
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 FAQ
(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 bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.
—————————————————————————–
SELinux bool variables:
Each service has its own ruleset. The Selinux bools can be found with the command getsebool
Here and example for the httpd service


[root@client1 ~]# getsebool -a | grep httpd
allow_httpd_anon_write –> off
allow_httpd_sys_script_anon_write –> off
httpd_builtin_scripting –> on
httpd_can_network_connect –> off
httpd_can_network_connect_db –> off
httpd_can_network_relay –> off
httpd_can_sendmail –> on
If you would start the apache server you would not be able to connect to it, because the httpd_can_network_connect is turned off. 


Set sebool to on:
[root@client1 ~]# setsebool -P httpd_can_network_connect =on
Now you are able to start the apache server and connect to it.


Selinux Manpage

[root@client1 ~]#man httpd_selinux
—————————————————————————–
Restore default security context of files or directories (File labeling):
Check filecontext:
[root@client1 ~]# ls -Z
drwxr-xr-x root root root:object_r:httpd_sys_content_t nagvis
drwxr-xr-x root root root:object_r:httpd_sys_content_t nconf


[root@client1 ~]# restorecon -v /var/www/html/index.html 


[root@client1 ~]# restorecon -Rv /var/www/html/index.html
 
To check if a restore is needed:
[root@client1 ~]# restorecon -Rv -n /var/www/html


Set new security context not persistent:
[root@client1 ~]# chcon -Rv –type=httpd_sys_content_t /html


Set new security context not persistent:
[root@client1 ~]# semanage fcontext -a -t httpd_sys_content_t “/html(/.*)?”
—————————————————————————–
Open non standard ports for httpd service:
[root@client1 ~]# semanage port -a -t http_port_t – p tcp 81


List all the ports managed permitted by selinux
[root@client1 ~]# semanage port -l
—————————————————————————–
Create selinux rule:
[root@client1 ~]# grep security_context_t /var/log/audit/audit.log | audit2allow -m nagios1 > nagios.te


now review the rules in the .te file.
Create selinux module:
[root@client1 ~]# grep security_context_t /var/log/audit/audit.log | audit2allow -M nagios1


Install the module:
[root@client1 ~]# semodule -i nagios1.pp




REFERENCES
http://www.salsaunited.net/blog/?p=89

Wednesday, June 2, 2010

Linux Kernel Security (SELinux vs AppArmor vs Grsecurity)

SkyHi @ Wednesday, June 02, 2010

Linux kernel is the central component of Linux operating systems. It is responsible for managing the system's resources, the communication between hardware and software and security. Kernel play a critical role in supporting security at higher levels. Unfortunately, stock kernel is not secured out of box. There are some important Linux kernel patches to secure your box. They differ significantly in how they are administered and how they integrate into the system. They also allow for easy control of access between processes and objects, processes and other processes, and objects and other objects. The following pros and cons list is based upon my personal experience.


SELinux


Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies for Linux kernel. It is included with CentOS / RHEL / Fedora Linux, Debian / Ubuntu, Suse, Slackware and many other distributions.


SELinux features


  1. Clean separation of policy from enforcement
  2. Well-defined policy interfaces
  3. Support for applications querying the policy and enforcing access control
  4. Independent of specific policies and policy languages
  5. Independent of specific security label formats and contents
  6. Individual labels and controls for kernel objects and services
  7. Caching of access decisions for efficiency
  8. Support for policy changes
  9. Separate measures for protecting system integrity (domain-type) and data confidentiality (multilevel security)
  10. Very flexible policy
  11. Controls over process initialization and inheritance and program execution
  12. Controls over file systems, directories, files, and open file descriptors
  13. Controls over sockets, messages, and network interfaces
  14. Controls over use of "capabilities"

Pros and Cons


  • Admin skill set (learning curve) - High
  • Complex and powerful access control mechanism - Yes
  • Detailed configuration required - Yes
  • GUI tools to write / modify rules set - Yes
  • CLI tools to write / modify rules set - Yes (see list of commands here)
  • Ease of use - No (often described as horrible to use)
  • Binary package - Available for most Linux distributions
  • System performance impact: None
  • Security Framework: Mandatory access controls using Flask
  • Auditing and logging supported - Yes
  • Typical user base - Enterprise users
  • Documentation - Well documented

=> Official project website : nsa.gov


AppArmor


AppArmor (Application Armor) is another security software for Linux which maintained and released by Novell under GPL. AppArmor was created as an alternative to SELinux. AppArmor works with file paths. According to official Novell FAQ:


AppArmor is the most effective and easy-to-use Linux application security system available on the market today. AppArmor is a security framework that proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good program behavior and preventing even unknown software flaws from being exploited. AppArmor security profiles completely define what system resources individual programs can access, and with what privileges. A number of default policies are included with AppArmor, and using a combination of advanced static analysis and learning-based tools, AppArmor policies for even very complex applications can be deployed successfully in a matter of hours.


AppArmor is default in OpenSUSE and Suse Enterprise Linux. It was first successfully packaged for Ubuntu Linux.


Features


  1. Full integration.
  2. Easy deployment.
  3. AppArmor includes a full suite of console and YaST-based tools to help you develop, deploy and maintain application security policies.
  4. Protects the operating system, custom and third-party applications from both external and internal threats by enforcing appropriate application behavior.
  5. Reporting and alerting. Built-in features allow you to schedule detailed event reports and configure alerts based on user-defined events.
  6. Sub-process confinement. AppArmor allows you to define security policies for individual Perl and PHP scripts for tighter Web-server security.

Pros and Cons


  • Admin skill set (learning curve) - Medium
  • Complex and powerful access control mechanism - Yes.
  • Detailed configuration required - Yes.
  • GUI tools to write / modify rules set - Yes (yast2 and wizards).
  • CLI tools to write / modify rules set - Yes.
  • Ease of use - Yes (often described as less complex and easier for the average user to learn than SELinux).
  • Binary package - Available for Ubuntu / Suse / Opensuse and distros.
  • System performance impact - None.
  • Security Framework - Mandatory access controls.
  • Auditing and logging supported - Yes.
  • Typical user base - Enterprise users.
  • Documentation - Documented (mostly available from Opensuse and Suse enterprise Linux).

=> Official project website : novell.com


grsecurity


grsecurity is a set of patches for the Linux kernel with an emphasis on enhancing security. It utilizes a multi-layered detection, prevention, and containment model. It is licensed under the GPL.


Features


  1. An intelligent and robust Role-Based Access Control (RBAC) system that can generate least privilege policies for your entire system with no configuration
  2. Change root (chroot) hardening
  3. /tmp race prevention
  4. Extensive auditing
  5. Prevention of arbitrary code execution, regardless of the technique used (stack smashing, heap corruption, etc)
  6. Prevention of arbitrary code execution in the kernel
  7. Randomization of the stack, library, and heap bases
  8. Kernel stack base randomization
  9. Protection against exploitable null-pointer dereference bugs in the kernel
  10. Reduction of the risk of sensitive information being leaked by arbitrary-read kernel bugs
  11. A restriction that allows a user to only view his/her processes
  12. Security alerts and audits that contain the IP address of the person causing the alert

Pros and Cons


  • Admin skill set (learning curve) - Low.
  • Complex and powerful access control mechanism - No (it is simpler to administer than other two implementations. Also, policies are simpler to create, since there are no roles or complicated domain/file transitions).
  • Detailed configuration required - No (works in learning mode).
  • GUI tools to write / modify rules set - No.
  • CLI tools to write / modify rules set - Yes (gradm tool).
  • Ease of use - Yes.
  • Binary package - Available for Ubuntu / RHEL / CentOS / Debian distros.
  • System performance impact - None.
  • Security Framework - Mandatory access controls (precisely, it is a RBAC implementation) using access control lists.
  • Auditing and logging supported - Yes.
  • Typical user base - Webserver and hosting companies.
  • Documentation - unfortunately, is not well documented.

=> Official project website : grsecurity.net


Conclusion:


All three offers very good protection and I can select them based upon the following simple criteria:


  • New user / ease of use : Grsecurity
  • Easy to understand policy and tools : AppArmor
  • Most powerful access control mechanism : SELinux












































FeatureSELinuxAppArmorgrsecurity
AutomatedNo (audit2allow and system-config-selinux)Yes (Yast wizard)Yes (auto traning / gradm)
Powerful policy setupYes (very complex)Yes Yes
Default and recommended integrationCentOS / RedHat / DebianSuse / OpenSuseAny Linux distribution
Training and vendor supportYes (Redhat)Yes (Novell)No (community forum and lists)
Recommend forAdvanced userNew / advanced userNew users
FeaturePathname based system does not require labelling or relabelling filesystemAttaches labels to all files, processes and objectsACLs

My personal choice is grsecurity as it is easier to use and offers many other security features. I've used SELinux as it is default choice under RHEL. AppArmor was only tested in lab under OpenSuse. I suggest you download and install all 3 patches (also available via binary deb and rpm files) and compare them as per your setup to gain a deeper understanding of their differences.


Resources: