Linux Security Overview

Matt Jamison

Gov’t Solutions Architectjamo@redhat.com

Source code:

#include <stdio.h>

int main (void)

{

printf("hello, world!\n");

return 0;

}

Binary code:

It’s ALL about the community!!!!

Well, not exactly...

How Open Source is changing our lives

Wikipedia

Mozilla Firefox

MIT - OpenCourseWare (OCW)

MIT - Open Source Building Alliance (OSBA)

SELinux

What’s next?

Open Source – A Better Way

Returns control.

Security reinforced through transparency.

Multiplies the development capacity.

Wired Magazine, Dec 2004

Bugs per 1000 Lines of Code

Linux 2.6 Kernel 0.17 Stanford University/CoverityProprietary Software 10 to 20 Carnegie Mellon Cylab

Critical flaws: days of risk

Time from an issue being known to the public until the day that a fix

is available via Red Hat Network.

Red Hat Enterprise Linux 4, Feb 2005-Feb 2007

Open source security Red Hat no longer does

Windows vulnerability

comparisons “because

Windows deliberately does

not disclose all their

vulnerabilities, making

vulnerability count

comparisons worthless“ - Mark Cox, Red Hat Security

Response Team Leader

One 2006 comparison:

Internet Explorer was

unsafe for 284 days

Firefox was unsafe for 9

days

Source: Washington Post

SELinux

SELinux: Background

Originated from NSA R&D.

First public release by NSA in Dec 2000.

Large and growing user and developer community.

Integrated into mainline Linux 2.6 in Aug 2003.

Found in many linux distributions be default

today.

Building Security Openly

NSA develops technology

for deeply extending security

of Linux

Integrated into the Open

Source Linux Kernel

Red Hat integrates into

sponsored Open Source

project

Red Hat enables by

DEFAULT in All Enterprise

Solutions

Customers, NSA, Community, and

Red Hat continue evolution...

Policy Type-Enforcement SELinux tags each and every process and file with a security

context to which it belongs

A security enforcement module in the kernel permits or

denies access to all objects (such as files and devices)

Kernel process decides which subjects (processes, users)

can access which objects

SELinux calls this Type Enforcement (TE)

Discretionary Access Control (DAC)

Strict Policy

Targeted Policy

SELinux – Limit Exploit Impact

SELinux is a flexible Mandatory Access Control architecture within

the standard Open Source Linux Kernel

Exploit

Exploit

Samba exploit, May 2007

2 Samba vulnerabilities to which the fix was issued at time of disclosure to public

No known exploits to exist for vulnerabilities which leveraged a heap overflow

We believe that the executable memory process checks in SELinux

would have prevented the exploit from executing writable memory.

While the exploit might be able to take advantage of a buffer overflow

when the attacker tries to execute the code, SELinux would stop it.

IF attacker gained root access

read/write to any files/directories labeled samba_share_t (expected)

read/write to /etc/samba/*, /var/log/samba/*, /var/spool/samba, /var/run/samba/*

create/read/write files created in /tmp by samba, nothing else

Outward/listen tcp connections on ports 631, 137-139, 445 and nsswitch ports

Read most files in /etc/, /usr/

Update the utmp file

Read and do all code used in nsswitch

What the attacker can't do

read/manipulate users home directories (how important is that?)

read/manipulate any databases on the system

Attack data/processes owned by other confined domains (200+ in

RHEL5)

Attack other machines via the network, other than ports mentioned

above.

Cannot send mail to become spam agent.

But wait, there's more

While the attacker is trying to do evil things on your machine, your audit logs will be capturing avc messages showing you what the attacker was trying to do. If you had setroubleshoot running, you would be receiving real time notification of these avc messages, and if you set it up to email, you would be getting emails about it.

What is Security-Enhanced Linux? Security-Enhanced Linux – Strong, flexible MAC architecture

Flask architecture allows for alternative security policies and

models

Initially a research prototype out of NSA; now part of the upstream

Linux 2.6 kernel

Growing community of use and development

With SELinuxWithout SELinux

Strict Policy

Definition :: System where everything is denied by default.

You must specify allow rules to grant access

Available for download and installation

Designed to be a very strict policy

Policy rules have only allows

Minimal privileges for every daemon

Separate user domains for programs like gpg, ssh, etc.

Default policy provided by NSA

Difficult to enforce in general purpose operating system

Meant for special, highly-purposed systems

Targeted Policy Definition :: System where everything is allowed, only deny

rules are used

Shipped with Red Hat Enterprise Linux 4

Enabled by default

Most processes run in unconfined_t domain

Unconfined processes run as if SELinux was disabled

Targeted daemons transition to locked down domains

httpd started by unconfined_t transitions to httpd_t

Provides containers for many commonly-used daemons

httpd, dhcpd, mailman, named, portmap, nscd, ntpd, mysqld,

postgresql, squid, syslogd, winbind, snmpd

SELinux Benefits

Remote Root Exploit (RRE) becomes harmless

http://www.coker.com.au/selinux/play.html

Feb 2003: Two machines connected to Internet with root

password on home page

No cracks reported (from Feb 2003 through May 2006)

Audit becomes very rich

Every object access by every role

100s of security errors found and fixed in typical Linux

distributions

MAC is the minimum for doing high-grade security in most Military

and Intelligence Communities

Security - SELinux Enhancements Expanded SELinux targeted policy coverage

Will provide coverage for all core system services, versus 11, 2 years ago

Inclusion of support for Multi Level Security (MLS) enforcement model under

consideration

In addition to existing RBAC and TE models

Security Certification and support with OEM partners

An additional level of protection against security exploits

Fine-grained policies via kernel-enforced mandatory access controls

Limits the scope of security vulnerabilities

Way beyond what any other general-purpose OS can deliver

Security – SELinux Enhancements Expanded SELinux targeted policy coverage

Provide coverage for 100+ core system services, versus 11 2

years ago (200+ packages)

Inclusion of support for MLS enforcement model

In addition to existing RBAC and TE models

EAL4+/LSPP

Retain flexibility and choice

One OS, rather than multiple, can be used for a variety of roles

Available policy models

Targeted with MCS (selinux-policy-targeted)

Strict with MCS (selinux-policy-strict)

Strict with MLS (selinux-policy-mls)

No separate “trusted” version

Common Criteria EAL4+/CAPP/LSPP/RBACPP

Multi-Level Security

Some critical scenarios require Multi-Level Security (MLS)

Bell-LaPadula (BLP) model

Focus is on confidentiality

Ensures users and programs on a system can only access resources

for which they have been appropriately cleared

Maintains the separation between different sensitivity (Top Secret,

Secret, Confidential, Unclassified) and categorization levels

“No read up; no write down”

Formerly the exclusive province of expensive, niche “trusted”

operating systems

Multi-Category Security

MCS = MLS with a single sensitivity level

Goal: prevent accidental leakage by the user of confidential documents,

etc.

User-focused, discretionary scheme

Analogous to the targeted policy; extend the benefits of preserving

confidentiality to a wider audience

Uses many of the same code paths as MLS

Available today in Fedora Core 5

Role-Based Access Control Implementing a MAC model on an OS is difficult

Defining rules for every user to allow access to every object would result

in an enormous set of rules With RBAC, administrators define roles and allow certain users access to

those roles e.g.:

Accountant Needs read and write access to accounts database No other permissions

Auditor Needs to read audit logs Needs to read configuration files Not allowed to write anything

Defining which objects certain roles can access, and allowing various

users to assume various roles, the task of defining a mandatory

access policy is greatly simplified

setroubleshoot setroubleshootd is a daemon which reads AVC

messages through the SELinux audit dispatcher.

It then runs these avc messages through a plugin

database of diagnosis solutions to the AVC.

It then reports the diagnosis to applications like sealert

in the form of a human readable description of the

error.

setroubleshoot setroubleshoot can notify users of an issue via email.

This is done by setting up the email section of

/etc/setroubleshoot/setroubleshoot.cfg.

Setroubleshoot can also use sealert to show the

messages to the user in the gui.

sealert notification

sealert browser

Setroubleshoot email

semanage semanage is used to configure certain elements of

SELinux policy without requiring modification to or

recompilation from policy sources.

This includes the mapping from Linux usernames to

SELinux user identities (which controls the initial

security context assigned to Linux users when they login

and bounds their authorized role set) as well as security

context mappings for various kinds of objects, such as

network ports, interfaces, and nodes (hosts) as well as

the file context mapping.

semanage Examples:

− View SELinux user mappings

$ semanage user -l

− Allow joe to login as staff_u

$ semanage login -a -s staff_u joe

− Add file-context for everything under /web (used by

restorecon)

$ semanage fcontext -a -t httpd_sys_content_t

"/web(/.*)?"

semanage Examples continued:

− Allow Apache to listen on port 81

$ semanage port -a -t http_port_t -p tcp 81

semodule Main tool for dealing with loadable policy modules.

Used for installing, upgrading, listing, and removing

modules.

semodule may also be used to force a rebuild of policy

from the module store and/or to force a reload of

policy without performing any other transaction.

semodule semodule acts on module packages created by

semodule_package.

Files created by semodule_package have a .pp suffix.

Examples:

− Viewing non-base policy modules on your system:

semodule -l

semodule Examples:

− Install a non-base policy package.

$ semodule -i httpd.pp

− Install a base policy package

$ semodule -b base.pp

− Replace all modules with the ones in the current

directory

$ semodule -b base.pp ‘semodule -l | awk ’{print "-i " $1

".pp"}’‘

Using audit2allow to Build Modules

You can use audit2allow and semodule together to

build policy modules.

If you are experiencing SELinux errors but and know

that these errors are blocking legitimate usage, then

you should cautiously consider using audit2allow. Be

aware that changes to your SELinux policy could

compromise the security of your system.

Using audit2allow to Build Modules

Say for instance, you are getting the following

message:

“type=AVC msg=audit(1164222416.269:22): avc:

denied { use } for pid=1940 comm="setsebool"

name="0" dev=devpts ino=2

scontext=system_u:system_r:semanage_t:s0

tcontext=system_u:system_r:init_t:s0 tclass=fd”

in your /var/log/audit/audit.log.

Using audit2allow to Build Modules

You know that everything is working correctly, but the

message is aggravating you.

As this message is about setsebool, you can isolate

just these messages by doing:

− ausearch -x setsebool | audit2allow

man ausearch for all of the possible options.

Using audit2allow to Build Modules

To generate a policy that will keep these messages

from occurring, do the following:

− ausearch -x setsebool | audit2allow -M

mysetseboolfix

Once this runs, you can insert the policy by doing:

− semodule -i mysetseboolfix.pp

apol

apol is a graphical tool to analyze a SELinux policy file.

Features

− Browse and search policy components.

− Search through Type Enforcement and other rules

− View File contexts from a filesystem.

− Perform automated, complex analyses of a policy.

apol

Current capabilities:

− Domain Transition

− File Relabel

− Types Relationship

− Information Flow Analyses

Few people will have any reasons to use apol.

Not many people have a need for policy analysis.

apol – Showing a Policy Summary

apol – Searching for Rules

apol – Performing a Domain

Transition Analysis

apol – Performing a Transitive

Information Flow Analysis

sediff sediff is a command line tool which enables the user to

take two policies and find semantic differences,

including added or removed:

− Types

− Users

− Roles

− Booleans

− Type Enforcement Rules

sediff The semantic difference of a policy is different from a

syntactic difference in that it shows the cumulative

effect of rules rather than doing a line-by-line

comparison.

man sediff for information on syntax – much like GNU

diff.

There is also sediffx, a GUI version of this tool.

sediffx in action

secon secon is a tool that enables you to see a context, from

a file, program or user input.

This tool is very useful in scripting.

[root@rhu1 ~]# secon

user: root

role: system_r

type: unconfined_t

sensitivity: s0

clearance: s0:c0.c1023

mls-range: s0-s0:c0.c1023

secon Common Options:

− secon -u (Show the user of the security context)

− secon -r (Show the role of the security context)

− secon -t (Show the type of the security context)

− secon -s (Show the sensitivity of the security

context)

− secon -c (Show the clearance level of the security

context)

secon For more information (including more options) on

secon, see “man secon”.

Different than Apparmor identifies file system objects by path name instead of

inode. This means that, for example, a file that is

inaccessible may become accessible under AppArmor

when a hard link is created to it, while SELinux would

deny access through the newly created hard link.

Novell fired all of their Apparmor developers

Apparmor and upstream adoptionI suspect that we're at the stage of having to decide between

a) set aside the technical issues and grudgingly merge this stuff [Apparmor] as a service

to Suse and to their users (both of which entities are very important to us) and leave

it all as an object lesson in how-not-to-develop-kernel-features. Minimisation of the

impact on the rest of the kernel is of course very important here.

Versus

b) leave it out and require that Suse wear the permanent cost and quality impact of

maintaining it out-of-tree. It will still be an object lesson in how-not-to-develop-kernel-

features.

Sigh. Please don't put us in this position again. Get stuff upstream before shipping it to

customers, OK? It ain't rocket science.

--Andrew Morton

The ExecShield Project

Reducing the risk of

unpatched issues

Buys time for patching

Break existing exploit

mechanisms

Increase Diversity

Make it hard for generic

exploits to work

ExecShield

NX/EDB

RandomizationPIE

Binaries

Run

TimeDetectio

n

Emulatio

n

kernel

glibcgcc

gcc

ExecShield

project

gcc

41.7% of reported CVE vulnerabilities

avoided with ExecShield

The ExecShield Project

Unpatched RHEL4 AS had zero critical bugs

15 Feb 05 to 14 Feb 06

Reality: Many customers perform security updates late or not at all Unpatched Win2000 compromised after 1h 17m on internet Unpatched Win2003 compromised after 1h 12s on internet Unpatched RHEL3 not compromised during 6week test (1008h)

Source:http://www.techworld.com/security/news/index.cfm?NewsID=5535

March 2006

Goal: Reduce the risk of entire classes of security vulnerabilities from being

exploited Analyze existing exploits and remove exploitable mechanisms 41.7% of reported CVE vulnerabilities avoided with ExecShield

Types of Exploitable Software Flaws

Based on 2004, Information collected by Steven M Christey from Mitre

Linux Operating System SecurityFeature Function Benefit

1

2

3 Reduces vulnerabilities of applications.

4 Auditing

5

6 Gcc/Glibc

Security Enhanced Linux

Enforces security policies with mandatory access controls for users and processes.

Provides a comprehensive solution to today's major security problem ­ 80% of security breaches today occur from inside an organization.

Exec Shield (Segmentation and NX/XD)

Software controls to prevent code execution in buffer overflow scenarios.

Thwarts hacker attacks. Prevents worms.

No­eXecute (NX) and eXecute­Disable (XD) support prevents AMD/Intel chips from executing code in buffer overflows.

Position Independent Executables

PIE randomizes application locations in memory.

Monitor, log, and analyze all system events.

Comprehensive event monitoring and meets new IT compliance requirements.

Certification(CAPP/EAL4+)

Provides assurance that platform is designed, reviewed, and tested to standard security engineering practices.

Meets government platform requirements.

Compile & run time buffer managements enhancements

Provide additional security from hacker attacks. Unique to Red Hat

Technology – Hardware

Support Previously could not protect against execution of readable

memory

Intel and AMD added NX support

Memory can be marked read or read/write

Extends to kernel memory as well

Creates some compatibility problems

Solved via ExecShield mechanisms

Technology –

Position Independent

Executables– Problem: Exec-Shield cannot randomize load address of

executables

– Solution: new kind of executables : PIE

• Cause some processing overhead

• recommended for programs accessible through the network

• First PIEs shipped in RHEL3, extended to cover all network

visible code in RHEL4

Technology – Automatic

Fortification

– Compiler and Library Enhancements

• Advanced GLIBC memory corruption checks

• Printf format string exploit prevention

• GCC buffer bound checking

Technology – Stack CanariesAutomatically generated canary:

int match (const char *p)

{

char tmp[MAXPASSWD];

...

}

Canary checked before return

value used

Parameters copied safely

Prevents many simple buffer

overflow flaws

Hardening Procedures

These are ground rules only!

Only you can provide a means of determining what data and

systems need to be secured.

Proper Passwords1. Choose a favorite movie line, such as “Aren't you a little short for a stormtrooper?” from Star Wars

2. Choose a favorite movie line, such as “Aren't you a little short for a stormtrooper?” from Star Wars

3. Then find a good place for at least one digit, such as the “s”, and replace it with a digit

4. This leaves us with “Ayal5fas?”

5. The resulting password is random enough to not be found in any dictionary search, but because the

user picked the quote to base it off of, it is easily memorized.

Pam based Password Rules Ensure /etc/pam.d/system-auth file permissions are 644

Edit /etc/pam.d/system-auth file, adding to the pam_cracklib.so

line:

− minlen=9 dcredit=-1

− This will cause a password length of 8 with 1 numeric character

PASS_MAX_DAYS 60

PASS_WARN_AGE 5

remember=6

Unnecessary Services anacron – Unless there are specific jobs scheduled using anacron, shut it down

and remove it. This scheduler is meant for systems that are frequently shut

down.

atd – Unless you regularly schedule jobs via AT, shut this down and remove it.

Currently all of Nomura's RHEL based systems use “cron” to schedule events.

rpcgssd – Unless the server is running NFS v4, this should be shutdown.

rpcidmapd – Unless the server is running NFS v4, this should be shutdown.

sendmail – Unless the server is specifically an MTA, shut this down.

telnet – Telnet should not be used, use SSH instead.

vsftpd – Unless the server is an FTP server, this should be removed. The scp

command should be used to transfer files.

xinetd – Unless there are specific services that need to be managed by xinetd,

this service should be shutdown.

iptables

* Use nmap, netstat -lp, and/or lsof -i to scan your host(s) for listening ports

* Document the need for each open port

* If something is running that shouldn't be, shut it down, remove it if possible

* Use iptables to lock down everything but the necessary listening ports.

/etc/sysconfig/iptables:

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT

-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT

-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Shell Registrations

A shell is a command interpreter that allows interaction between

the user and the operating system. The default shell for RHEL

is bash, but other shells are available for use in RHEL.

Determine what shells are currently used, and remove the rest

from /etc/shells.

The “/sbin/nologin” entry is not a really a shell, just a method of

deny login rights to a particular user. The remaining shells can

be removed from the “/etc/shells” text file, there by disallowing

their use.

OS Version Display and Add Legal Banner

The default “/etc/issue” file displays the operating system version as

well as the running kernel version. This information should be

changed on production servers to display a legal warning instead.

Edit the /etc/issue file and change the listed OS. This way you are not

telling potential “crackers” which operating system is on the system.

Add to /etc/issue an appropriate warning banner that warns of legal

ramifications.

Copy /etc/issue to /etc/issue.net and /etc/motd.

Ensure permissions for the three files are 644.

Disable Compilers, Sniffers, and Interpreters Compilers convert source code in languages such as “C” and “C++”

into executable binary applications. There is usually no need to have

a compiler on production servers, so such software should be

relegated to development workstations. Additionally, network

scanning software should be removed from production servers. These

tools should not be on production servers because they may

introduce potential security risks.

Remove applications such as gcc, cc, adb, dbx, dbxtool, javac, jdb,

tcpdump, snort, dig, firewalk, hunt, ipgrab, nc (netcat), nmap, ntop,

queso, spak, strobe, and tcp_scan.

If any of these tools are required, create a special group of servers

and restrict access to the systems in that group.

Harden System Accounts

System accounts refer to “users” that are created by default at installation

time. They normally do not have valid passwords or “home” accounts. The

danger is that someone could potentially use one of these accounts to cause

damage. By removing unnecessary accounts, this risk is mitigated.

Backup /etc/shadow and /etc/passwd

Remove all unnecessary accounts from /etc/shadow and /etc/passwd. There

are around 40+ accounts created on any given system, most of which can

be removed.

Adm, desktop, ftp, games, gdm, gnats, gopher, identd, irc, list (if not using

Mailman), lp (if not printing), lpd (if not printing), mailnull (if not using

Sendmail), news, nfsnobody, operator, proxy, rpc, rpcuser, sync, uucp,

telnetd (when telnet is removed from use), www-data, xfs

Setuid/Setgid Inventories The setuid and setgid permissions allow certain commands to run as the root

user. For instance, the passwd command is used to change user passwords.

The setuid bit is set for this command so that a user can change the

password on his account. Leaving the passwd program in place with the

setuid bit set is, therefore, a necessary risk. The best way to protect against

the wrong commands being modified with the setuid bit is to make a listing of

all the enabled commands, and monitor the list for changes.

Create an inventory of all setuid and setgid enabled files with the following

command:

find / -perm -4000 -o -perm -2000 -type f -print > set.inv

Copy that file to a secure location and periodically re-run the find command

and diff it against the original to ensure that no unauthorized changes have

been made.

Block Use of .netrc The “.netrc” file contains user defined configurations for FTP, a

very insecure protocol used for moving files between networked

systems. It is too easy to have a security hole opened up via the

“.netrc” file. The best way to mitigate this is to create the file

without any content and then remove the ability for normal

users to change this.

Create an empty .netrc in each home directory (via /etc/skel)

Change permissions on .netrc to 000

NFS (Network File System) This is the most wide spread Linux and Unix based file sharing protocol, but

unfortunately it is inherently insecure. Yet it is used for some of the most

sensitive data in some of the largest datacenters. There is not much that can be

done to secure NFS, but here are some tips:

* Keep NFS, portmap (or rpcbind) up to date, as well as any NFS related

security patches

* Do not publicly export file systems, be specific at the NFS server configuration

* Export NFS file systems as “read only” whenever possible

* Disable use of “setuid” files on NFS by using the “nosuid” option in

“/etc/fstab”

* Block ports 2049 and 111 from all internet facing systems

* Consider moving to NFS v4, but this is a very different protocol

Resourceshttp://www.redhatmagazine.com/2007/08/21/a-step-by-step-guide-to-building-a-new-selinux-policy-module/

http://www.redhat.com/magazine/006apr05/features/selinux/

http://www.ibm.com/developerworks/linux/library/l-seclnx3/

http://www.ibm.com/developerworks/linux/library/l-seclnx1.html