CTEC2912: LINUX SECURITY
LECTURE 6: SELINUX & KERNEL SECURITY PATCHES
LECTURE CONTENT
• SELinux
• Forms of Access Control
• Kernel Security Patches
SELINUX
MAC VS DAC
• Discretionary Access Control
• Access decisions are based on user identity and ownership of the object in question
•
e.g rwx permissions in Linux are set by the owner
• Each user (and programs run by the user) has complete discretion over their objects
• Malicious, flawed or mis-configured programs can do anything with the files and resources it controls based on the named user who
started the process
• e.g processes running amok and consuming all resources
• if the user uid 0 (or the process is SUID 0 or SGID 0), the process has full control over the entire FS and all system resources
MAC VS DAC
• Mandatory Access Control
• Authorisation decisions are based on all the security relevant information in the policy, not
just the UID.
• Allows you to set granular permissions for:
•
users; files; directories; processes; process files; devices; sockets; ports; FIFOs; etc.
SELINUX
•
Written by NSA, is a LSM which is shipped with many Linux distributions (including Android).
•
Implements variety of access control models for users and processes against resources such as files/devices/networks/IPC etc.
•
Mandatory Access Control (MAC)
•
Role-Based Access Control (RBAC)
•
Centralised policy tells the kernel how different components may interact with one another
•
For example, a user may do anything in their home directory, but when running a web browser, policy may disallow access to ssh keys . . .
•
Requires a file system that can store security attributes, i.e. security labels.
SELINUX USE
• SELinux is not a replacement for DAC
• Instead, it is an additional security layer
• DAC rules are still used when using SELinux
• DAC rules are checked first and, if access is allowed, then SELinux policies are checked
• If DAC rules deny access, SELinux policies are not reviewed
SELINUX USE
• SELinux is the default security enhancement of Red Hat distributions
• You can install SELinux on Debian by using the command
• sudo apt install selinux
• and then rebooting
SELINUX PERCEIVED BENEFITS
• Can implement the Role Based Access Control (RBAC) model
• considered the best access control model by many
• Uses least privilege access for subjects
• for example, users and processes
• least privilege means that every subject is given a limited set of privileges that are only
enough to execute its tasks.
• with least privilege implemented, a user or process is limited in the accidental or
deliberate damage to objects they can cause
SELINUX PERCEIVED BENEFITS
•
Allows process sandboxing
•
each process runs in its own area separate domain
•
It cannot access other processes or their files unless special permissions are granted
•
Allows a test of its functionality before implementation
•
•
SELinux has a Permissive mode, which allows you to see the effect of enforcing SELinux on your
system
Similar to AppArmor Complain
SELINUX INTRODUCTION
• All users processes and files are labelled with a type
•
A type defines a domain for processes
• Running processes in their own domain separates them from one another
• SELinux policy rules define how processes can interact with both files and other processes
• Access is allowed only if a SELinux policy exists which explicitly allows it
• SELinux policy is not set at user discretion, instead it is designed by an administrator and enforced system wide
•
i.e. mandatory
USERS
• user attribute is a mapping of a Linux username to an SELinux name
• Not the same as a user’s login name
• Referred to specifically as the SELinux user
• SELinux username ends with a “u”
ROLES
•
A designated role in the company is mapped to an SELinux role name
• The role attribute is assigned to various subjects and objects
•
Each role is granted access to other subjects and objects based on the role’s security clearance and the object’s classification level
•
Users are assigned a role and roles are authorized for particular types or domains
•
Roles can constrain accounts, such as root, into fewer privileges
• The SELinux role name has an “r” at the end
WEB SERVER SCENARIO
• Consider what could happen if SELinux is not running
• Web server daemon (httpd) is listening on a port
• receives a simple request from a web browser to view a home page
• httpd daemon hears the request and only “traditional” Linux security is applied
• httpd usually runs as a privileged process
WEB SERVER SCENARIO
• httpd is able to:
• Access any file or directory, based on read/write/execute permissions for the associated owner and group
• Perform potentially insecure activities, such as allow a file upload or change system limits
• Listen on any port it likes for incoming requests
• On a system constrained by SELinux, the httpd daemon is much more tightly controlled
• httpd can only listen on the port SELinux allows it to listen on and access files of the same type
FORMS OF ACCESS
CONTROL
FORMS OF ACCESS CONTROL
• Enforcement
• Targeted
•
•
•
•
Usually default
Unless explicitly set, every process runs as unconfined
Strict enforcement to those processes set with policy
Permissive enforcement to unconfined processes
FORMS OF ACCESS CONTROL
• Strict
• Every process is monitored and policies are strictly adhered to
• Policy types
• RBAC
• MLS (Multilevel Security)
• Military grade clearance levels:
•
• etc.
Confidential, Secret, Top Secret
THE SECURITY CONTEXT: LABELS
• The label is made up of 3 or 4 components, separated by a “:”
• Fields are :
• user:role:type:level
• Example:
• system_u:object_r:net_conf_t:s0
• Labels should be defined for all file system objects
TYPES
• Type
• attribute defines a domain type for processes, a user type for users, and a file type for
files
• Assigning a type is a method of grouping items based on their similarity from
a security viewpoint
• Policy rules allow certain domains and roles to access certain object types
• Key element in Type Enforcement
TYPES
• For example, every process runs in a domain
• assigned domain type directly determines
•
•
each process’s access to the various file types
access to other processes’ domain types
• Most policy rules are concerned with what security types have access to what
other security types
• The SELinux type name ends with a “t”
LEVEL
• Attribute of Multilevel Security (MLS) enforcing the Bell-LaPadula model
• Optional
•
but required if using MLS
• The MLS level is a combination of the sensitivity and category values that
together form the security level
• A level is written as sensitivity : category
LEVEL - SENSITIVITY
• Sensitivity
•
•
•
•
Represents the security or sensitivity level of an object, such as confidential or top secret
is hierarchical with s0 (unclassified) typically being the lowest
is listed as a pair of sensitivity levels (lowlevel-highlevel) if the levels differ
is a single sensitivity level (s0) if there are no low and high levels, but the range may still
be shown (s0-s0)
LEVEL - CATEGORY
• Category
• represents the category of an object
•
such as No Clearance, Top Clearance, etc.
• Traditionally, the values are between c0 and c255
• Listed as a pair of category levels (lowlevel:highlevel) if the levels differ
• Listed as a single category level (level) otherwise
USER CONTEXT
• To see your SELinux user context, enter the id command at the shell prompt.
$ id
uid=1000(johndoe) gid=1000(johndoe) groups=1000(johndoe)
context=unconfined_u:unconfined_r:unconfined_t:s0s0:c0.c1023
USER CONTEXT
• The user’s security context list shows the following:
• user
•
The Linux user, johndoe, is mapped to the SELinux unconfined_u user
• Role
•
The SELinux user, unconfined_u, is mapped to the role of the unconfined_r
• Type
•
The user has been given the type of unconfined_t
• Level
•
Sensitivity
•
•
The user has only one sensitivity level and it is the lowest level of s0
Categories
•
The user has access to c0.c1023, which is all categories (c0 through to c1023)
FILE AND PROCESS CONTEXTS
• Files and processes also have security contexts with the same four attributes
• To see a file’s context, use the -Z option on the ls command.
$ ls -Z my_stuff
-rw-rw-r--. johndoe johndoe
unconfined_u:object_r:user_home_t:s0 my_stuff
#user= unconfined_u user, role=object_r,type=user_home_t
domain, level— sensitivity=s0 # categories not set
FILE AND PROCESS CONTEXTS
•
To see a process’s security context, you need to use the -Z option on the ps command.
# ps -eZ| grep bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 1589
pts/000:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 5289
pts/100:00:00 bash
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 5350
pts/100:00:00 bash
SELINUX POLICY RULES
• Policy rules are used by SELinux to determine if a subject has access to an object
• The rules allowing access are called “allow rules” or “policy rules.”
• SELinux serves as the guard who must see the user’s security context (analogous to an ID badge) before allowing or denying
access to an object
• Thus, Type Enforcement ensures that only certain “types” of subjects can access certain “types” of objects
• Access depends upon the policies in force
SELINUX MODES OF OPERATION
• Disabled → Enforcement is switched off. No creation of labels will take place on new files
• Permissive → The LKSM will still create labels, and access violations to the policy will be reported, but if the DAC permits the
access, then SELinux will permit the access
• Enforcing → The LKSM will create labels, access violations to the policy are reported, and access only granted if the security
policy has explicitly allowed it
• Access violations are reported using the Linux Auditing Framework (auditd)
SECURITY CONTEXT PROBLEMS
• cp and mv both behave very differently when put into an SELinux context.
• mv will maintain the security label (context) of a file when it is moved.
• when you cp over the top of an existing file, the new file inherits the security label.
• when you cp a file to a new file, the file inherits the label of its parent directory. There
are other possibilities as well.
INSTALLING SELINUX
• Some distributions come with SELinux already installed, perhaps in Permissive
mode (occasionally in Enforcing mode)
• Usually, you will need to set up on a machine already in production
• Begin by making sure that you are in permissive mode, then labelling the files
• Once complete, start building policies
• Read http://selinuxproject.org/page/Building_a_Basic_Policy
INSTALLING SELINUX
• Most policy changes can be made using boolean changes using setsebool. e.g.
• setsebool httpd_enable_homedirs on
• semanageport -a -t httpd_port_t -p tcp 8080
• Other graphical applications exist to allow these kind of settings to be
changed
SELINUX AWARE APPLICATIONS
• Most programs don’t need to be compiled with SELinux awareness
• the SELinux authorisation system lives in the Kernel as a Linux Kernel Security Module
• If access is denied, then the process will receive a standard E_NO_ACCESS response
SELINUX AWARE APPLICATIONS
• Some applications need to be aware
• coreutils such as ls, ps, find etc
• Login utilities which need to set the security context for a user
• SELinux core applications
•
setenforce, getenforce, load_policy, check_policy, check_module etc.
POLICY INTEGRATION
• Policy files are a lot like applications compiled from source code
•
•
•
•
build the policy
check the policy
compile to a binary format
install to the kernel module
KERNEL
SECURITY
PATCHES
PAX
•
A source patch for the Linux kernel which implements least privilege protections for
memory pages
•
Most exploits against processes are due to significant weaknesses when dealing with
user input. This can lead to processes being re-written during execution, often leading
to:
•
•
•
•
Root access.
Remote file system access.
Other potentially damaging situations.
PaX protects against this by causing such behaviour to simply end the life of the
process (local DOS)
PAX PROTECTIONS
• Executable space protection (or the NX bit - sometimes emulated).
• Restricted mprotect() (no memory area can be W|X)
• ASLR
• Randomise mmap() base (random VM offset, libraries will shift).
• Above protections can be set in the ELF header, too, using paxctl.
PAX
• PaX does not solve the security problems, it merely mitigates the risk of:
• introduce/execute arbitrary code
• execute existing code out of original program order
• execute existing code in original program order with arbitrary data
GRSECURITY
•
A series of patches for the Linux kernel which implement many security enhancements (including PAX).
• RBAC - least privilege system.
• chroot restrictions
•
Prevent vulnerabilities & privilege escalations
• Kernel auditing of:
•
•
•
•
•
Users.
Mounting/Unmounting.
Date/Time changes. Denied
resource attempts
Failed fork()
GRSECURITY
• Trusted path execution
• /proc hardening
• Prevent information leaking about process owners
• symlink and hardlink restrictions to prevent /tmp races
• Attacker creates file /tmp/foo
• Attacker creates infinite loop rm -f /tmp/foo; ln -s /etc/shadow /tmp/foo
• Eventually, get a point where OS checks that user has write access to foo, then opens /etc/shadow for writing because foo
has been deleted.
READING & REFERENCES
•
http://www.omnisecu.com/gnu-linux/redhat-certified-engineer-rhce/what-is-security-enhanced-linuxselinux.php
•
http://selinuxproject.org/page/Building_a_Basic_Policy
•
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/SecurityEnhanced_Linux
•
https://wiki.centos.org/TipsAndTricks/SelinuxBooleans
•
https://wiki.centos.org/HowTos/SELinux
•
https://pax.grsecurity.net/docs/pax.txt
•
https://en.wikibooks.org/wiki/Grsecurity
•
https://capec.mitre.org/data/definitions/27.html
POST-LECTURE SELF-STUDY TASKS
Discuss the following questions:

Compare and contrast misuse prevention and anomaly prevention

Summarise how AppArmor protects an operating system
LECTURE SUMMARY
• SELinux
• Kernel Security Patches
• PaX
• grsecurity