Linux/SELinux

From Omnia
Jump to: navigation, search

SELinux

SELinux - http://www.nsa.gov/selinux/

Wiki: SELinux - http://en.wikipedia.org/wiki/SELinux

SELinux has two major components on your system.: [1]

  • The kernel mechanism which is enforcing a bunch of access rules which apply to processes and files.
  • File labels : every file on your system has extra labels attached to it which tie-in with those access rules. Run ls -Z and you'll see what I mean.

Useful Commands

SELinux Status

Disable SELinux:

setenforce permissive
setenforce 0
echo 0 > /selinux/enforce

Enable SELinux:

setenforce enforcing
setenforce 1
echo 1 > /selinux/enforce

See SELinux Status:

# getenforce
  Enforcing
### sestatus - SELinux status tool

# sestatus

     SELinux status:  enabled
     Current mode:    enforcing

     SELinux status:  enabled
     Current mode:    permissive

     SELinux status:  disabled

File Context

List file/folder's context:

ls -laZ

Manually change a folder's context:

chcon -t home_root_t /home
chcon -R -t user_home_t minecraft
chcon -R -t ssh_home_t minecraft/.ssh

---

Fixing Denials

Try restoring SELinux contexts first:

# restorecon - restore file(s) default SELinux security contexts.
restorecon -R -v /some/path

Install audit2allow:

yum install policycoreutils-python

See sample new policy

grep httpd /var/log/audit/audit.log | audit2allow -m mypol
grep httpd /var/log/audit/audit.log | audit2allow -m mypol > mypol.te

To manually compile the Type Enforcement (TE) file to a policy file (.pp): [2]

MODNAME=mypol
checkmodule -M -m -o $MODNAME.mod $MODNAME.te
semodule_package -o $MODNAME.pp -m $MODNAME.mod
semodule -i $MODNAME.pp

build.sh:

#!/bin/bash
if [ "$1" == "" ] ; then
  echo "Usage: $0 [policy]"
  echo "Note: It is recommended to clear /var/log/audit/audit.log before"
  echo "      testing and creating a policy, to remove old cruft."
  exit 1
fi
MODNAME=$1
grep $MODNAME /var/log/audit/audit.log >> $MODNAME.log
cat $MODNAME.log | sort | uniq > $MODNAME.log.1
mv $MODNAME.log.1 $MODNAME.log
cat $MODNAME.log | audit2allow -M $MODNAME
#cat $MODNAME.log | audit2allow -m $MODNAME >> $MODNAME.te
#checkmodule -M -m -o $MODNAME.mod $MODNAME.te
#semodule_package -o $MODNAME.pp -m $MODNAME.mod
semodule -i $MODNAME.pp

Create new policy

grep httpd /var/log/audit/audit.log | audit2allow -M mypol
# cat mypol.te
semodule -i mypol.pp
# service httpd restart

If a comment says to enable a bool

setsebool -P samba_export_all_rw on

Remove new policy:

semodule -r mypol.pp

Get explanation:

tail -f /var/log/audit/audit.log | grep ' avc: ' | tee /tmp/error.txt
audit2why -i /tmp/error.txt

References:

Security-Enhanced Linux - NSA/CSS

As part of its Information Assurance mission, the National Security Agency has long been involved with the computer security research community in investigating a wide range of computer security topics including operating system security. Recognizing the critical role of operating system security mechanisms in supporting security at higher levels, researchers from NSA's National Information Assurance Research Laboratory have been investigating an architecture that can provide the necessary security functionality in a manner that can meet the security needs of a wide range of computing environments.

End systems must be able to enforce the separation of information based on confidentiality and integrity requirements to provide system security. Operating system security mechanisms are the foundation for ensuring such separation. Unfortunately, existing mainstream operating systems lack the critical security feature required for enforcing separation: mandatory access control. As a consequence, application security mechanisms are vulnerable to tampering and bypass, and malicious or flawed applications can easily cause failures in system security.

The results of several previous research projects in this area have yielded a strong, flexible mandatory access control architecture called Flask. A reference implementation of this architecture was first integrated into a security-enhanced Linux® prototype system in order to demonstrate the value of flexible mandatory access controls and how such controls could be added to an operating system. The architecture has been subsequently mainstreamed into Linux and ported to several other systems, including the Solaris™ operating system, the FreeBSD® operating system, and the Darwin kernel, spawning a wide range of related work.

The architecture provides a mechanism to enforce the separation of information based on confidentiality and integrity requirements. This allows threats of tampering and bypassing of application security mechanisms to be addressed and enables the confinement of damage that can be caused by malicious or flawed applications.

This work is not intended as a complete security solution. It is not an attempt to correct any flaws that may currently exist in an operating system. Instead, it is simply an example of how mandatory access controls that can confine the actions of any process, including an administrator process, can be added into a system. The focus of this work has not been on system assurance or other security features such as security auditing, although these elements are also important for a secure system.

The security mechanisms implemented in the system provide flexible support for a wide range of security policies. They make it possible to configure the system to meet a wide range of security requirements. The reference implementation included a general-purpose security policy configuration designed to meet a number of security objectives as an example of how this may be done. The flexibility of the system allows the policy to be modified and extended to customize the security policy as required for any given installation.

There is still much work needed to develop a complete security solution. Nonetheless, we feel we have presented a good starting point to bring valuable security features to mainstream operating systems. We are looking forward to building upon this work with other developers and users. Participation with comments, constructive criticism, and/or improvements is welcome.

Performance

How does SELinux impact system performance?

"This is a variable that is hard to measure, and is heavily dependent on the size of the system SELinux is running on. When performance was last measured, the impact was around 7% for completely untuned code. Changes since then are likely to have made that worse in some cases, such as networking. SELinux performance tuning will be a priority of the development team." [3]

Other articles indicate that the overhead increases significantly as the number of CPUs increases.

Status

sestatus:

[root@testf8 ~]# /usr/sbin/sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 21
Policy from config file:        targeted

selinuxenabled:

/usr/sbin/selinuxenabled ; echo $?
# 0 means enabled
# 1 means disabled

Disabling

Should I disable SELinux?

"Joshua Brindle (an SELinux developer) has comments on disabling SELinux, which states clearly that applications should be fixed to work with SELinux, rather than disabling the OS security mechanism. "

For the operating system as a whole, there is two kinds of disabling: [4]

  • Permissive - switch the SELinux kernel into a mode where every operation is allowed. Operations that would be denied are allowed and a message is logged identifying that it would be denied. The mechanism that defines labels for files which are being created/changed is still active.
  • Disabled - SELinux is completely switched off in the kernel. This allows all operations to be permitted, and also disables the process which decides what to label files & processes with.

Disabling SELinux and then enabling will mean a full re-labeling of the file system:

"Disabling SELinux could lead to problems if you want to re-enable it again later. When the system runs with file labelling disable it will create files with no label - which could cause problems if the system is booted into Enforcement mode. A full re-labelling of the file system will be necessary." [5]

Temporarily switch off enforcement:

echo 0 >/selinux/enforce

You'll need to be logged in as root, and in the sysadm_r role:

newrole -r sysadm_r

To switch back into enforcing mode:

echo 1 >/selinux/enforce

In Fedora Core and RedHat Enterprise Linux you can use the setenforce command with a 0 or 1 option to set permissive or enforcing mode, its just a slightly easier command than the above.

# set permissive mode:
setenforce 0

# set enforcing mode:
setenforce 1

To check what mode the system is in:

cat /selinux/enforce

Permanently Permissive

edit /etc/selinux/config

/etc/selinux/config

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

To Read


SELinux — is it *really* too complex?

References

PLUG SELinux Presentation

Date: December 10th, 2008
Time: 7:30 PM - 9:30 PM
Location: Omniture, Inc.


December Meeting: SELinux | PLUG - Provo Linux Users Group

Stuart Jansen, instructor, author and chief bottle washer at Guru Labs, will be presenting An Introduction to SELinux.

The traditional Unix security model is simple and beautiful. For decades it has been good enough for most people. However, it is starting to show its age. In the highest security settings, a more fine grained control system is needed. In the past, this meant using expensive, complicated, special purpose versions of Unix: trusted systems. (Trusted Solaris, Trusted AIX, Trusted HP-UX)

SELinux, created by the NSA, is the most mature and complete response to the need for Trusted Linux systems. Unfortunately, because of the difficulty creating and maintaining trusted systems, their success has been limited. This is no longer acceptable.

Today, even desktop systems and cell phones need high quality security. Imagine being able to sandbox your Web browser and e-mail client. The traditional Unix model makes this difficult and only partially possible. SELinux, on the other hand, makes fine grained security available to everyone.

When it first appeared, SELinux was hard to learn and mysterious to troubleshoot. As a result, many people fear it. However, SELinux and the tools to manage it have come a long way. It's time to lay fear aside. Stuart will teach what SELinux is, why it is great, basic troubleshooting and maintenance.


PLUG: December 2008 Meeting - SELinux by Stuart Jansen Podcast:

The traditional Unix security model is simple and beautiful. For decades it has been good enough for most people. However, it is starting to show its age. In the highest security settings, a more fine grained control system is needed. In the past, this meant using expensive, complicated, special purpose versions of Unix: trusted systems. (Trusted Solaris, Trusted AIX, Trusted HP-UX)

SELinux, created by the NSA, is the most mature and complete response to the need for Trusted Linux systems. Unfortunately, because of the difficulty creating and maintaining trusted systems, their success has been limited. This is no longer acceptable.

Today, even desktop systems and cell phones need high quality security. Imagine being able to sandbox your Web browser and e-mail client. The traditional Unix model makes this difficult and only partially possible. SELinux, on the other hand, makes fine grained security available to everyone.

When it first appeared, SELinux was hard to learn and mysterious to troubleshoot. As a result, many people fear it. However, SELinux and the tools to manage it have come a long way. It’s time to lay fear aside. Stuart will teach what SELinux is, why it is great, basic troubleshooting and maintenance.


Podcast Download | Ogg Vorbis | 62MB | 87:15min (.ogg)


Open Source TV - Stuart Jansen at PLUG meeting 10 December 2008:

"PLUG - Stuart Jansen on SELinux
Stuart Jansen of Guru Labs gives an introduction to Security-Enhanced Linux, or SELinux.
More info...
The traditional Unix security model is simple and beautiful. For decades it has been good enough for most people. However, it is starting to show its age. In the highest security settings, a more fine grained control system is needed. In the past, this meant using expensive, complicated, special purpose versions of Unix: trusted systems. (Trusted Solaris, Trusted AIX, Trusted HP-UX)
SELinux, created by the NSA, is the most mature and complete response to the need for Trusted Linux systems. Unfortunately, because of the difficulty creating and maintaining trusted systems, their success has been limited. This is no longer acceptable.
Today, even desktop systems and cell phones need high quality security. Imagine being able to sandbox your Web browser and e-mail client. The traditional Unix model makes this difficult and only partially possible. SELinux, on the other hand, makes fine grained security available to everyone.
When it first appeared, SELinux was hard to learn and mysterious to troubleshoot. As a result, many people fear it. However, SELinux and the tools to manage it have come a long way. It's time to lay fear aside. Stuart will teach what SELinux is, why it is great, basic troubleshooting and maintenance.

Related links:"

Presentation Notes

Commands:

# show SELinux status
# getenforce - get the current mode of SELinux
getenforce

# more verbose status
# sestatus - SELinux status tool
sestatus

# show counters for selinux
# seinfo - SELinux policy query tool
seinfo
# Set to permissive mode:
# setenforce - modify the mode SELinux is running in:
setenforce 0

# Set back to enforcing mode:
# setenforce - modify the mode SELinux is running in:
setenforce 1

Policies:

targeted - Only targeted network daemons are protected. (policy created by Redhat)
         - Protect those items that are most attacked
strict - Full SELinux protection. (original, too strict, gave SELinux a bad name)

Labels: (core commands modified to use labels)

# show labels
ls -Z
# files use types (labels)
# show process labels
ps -Z
ps -eZ
# processes use domain of process (still a label)

Modify Labels:

chcon - change SELinux security context
# change type for file
chcon -t httpd_sys_content_t index.html

# change type, but use reference file
chcon --reference=/var/www test

restorecon - restore file(s) default SELinux security contexts.
restorecon -r /var/www

fixfiles - fix file SELinux security contexts.

Note: Most commonly used types will be memorized over times.

SELinux Universal rule: can't execute code on your own stack

Use 'cp' instead of 'mv' if you want the correct permissions to happen.

Cheats:

  1. use reference:
    chcon --reference=/var/www/ index.html
  2. restore - use default for location
    restorecon index.html
  3. fixfiles - similar to restorecon, but uses rpm details
    fixfiles
  4. use copy over mv (mv retains permissions)

GUI tool for SELinux:

system-config-selinux

Note: Files don't get labeled if you are running in disabled mode. If you select "relabel on reboot" you can fix this, but it will take awhile. Relabel can be done from system-config-selinux or manually:

touch /.autorelabel
# /etc/rc.d/rc.sysinit

Booleans - allow parts of a policy to be controlled (turned on/off)

  • ie. Boolean to turn off SELinux protection for apace

If you can't find the appropriate boolean, you haven't looked hard enough:

getsebool - get SELinux boolean value(s)

# show all booleans
getsebool -a

setsebool - set SELinux boolean value

# make permanent with -P
setsetbool -P ...

semanage - SELinux Policy Management tool

# show default label rules
# list all rules for labeling files
semanage fcontext -l

Logs:

avc - authorization vector cache (caches selinux stuff to make faster)

grep avc /var/log/messages
grep avc /var/log/(messages,/audit/audit.log)

setroubleshoot - graphical tool to help (installed from another RPM)

setroubleshoot-server (rpm) for servers, puts messages into log files

# is it setroubleshoot -server or setroubleshoot-server?
grep sealert /var/log/messages
sealert

Can then copy paste logged command to get same details as the GUI version

source context and target context

Troubleshooting selinux problems:

  1. switch to permissive mode and see if problem resolves
  2. check the logs files to determine which file needs permission fixed
  3. use chcon, restorecon fixfiles, etc
  4. Check the booleans to see if there is somthing you need
  5. system-config-selinux or semanage if you need to modify ports
  6. Am I willing to write my own policy?
  7. Am I willing to turn off SELinux?

Give pretty flexible access to a file:

# read only access
chcon -t public_content_t [FILE]

# read write access
chcon -t public_content_rw_t [FILE]
chcon --reference [path] [file]
restorecon -R [path] [file]
fixfiles

memorize the one type:

public_content_t - public read mode - it is helpful many places
public_content_rw_t - read/write version

sesearch - SELinux policy query tool

man pages for details of various policies:

# ie.
man httpd_selinux

Kernel booting parameters:

# permissive mode
enforcing=0
# disabled
selinux=0

xguest - for creating kiosk style systems