Linux Kernel Security: Adapting 1960s Technology to Meet 21st Century Threats

Preview:

DESCRIPTION

Unix was not designed with security primarily in mind. It was initially developed in the late 1960s -- before the Internet was invented. While relatively simple, the Unix security model is inadequate for protecting against common security threats. Its designers identified fundamental design flaws over thirty years ago. As Linux is modeled on Unix, it inherits this traditional Unix security model. Meeting modern security requirements has required significant enhancements to Linux, which are ongoing, but well-advanced. While many new security ideas have emerged, Linux developers have necessarily been constrained by decades of operating system standards and conventions. Aimed at admins, developers and technical managers, the talk will cover:* The historical context of Linux security * Modern security OS requirements * How these requirements are being addressed (or not) by various enhancements made to Linux security * Areas of ongoing and future work. We'll also consider how FOSS culture contributes to security.

Citation preview

Linux Kernel Security

Adapting 1960s Technology to Meet 21st Century Threats

James MorrisRed Hat

LinuxCon Boston 2010

History

Fig. 1

“The first fact to face is that UNIX was not developed with security, in any realistic

sense, in mind; this fact alone guarantees a vast number of holes.”

Dennis Ritchie, “On the Security of UNIX”, 1979

Unix DAC

Fig. 2

DAC is “simple” and somewhat effective, but inadequate for modern environment:

Does not protect against flawed or malicious code

(Actually, DAC is not simple)

Fig. 3

“It must be recognized that the mere notion of a super-user is a theoretical, and usually practical,

blemish on any protection scheme.”

(also from Ritchie 1979)

Enhanced DAC

Fig. 4

POSIX Capabilities (privileges)

Access Control Lists (ACLs)

Namespaces

Fig. 5

Network Access Control

Netfilter

iptables

ebtables

Fig. 6

CryptographyFig. 7

Disk Encryption:

dm-cryptecryptfs

Network Encryption:

IPsec

ASLR

NX

GCC

/dev/mem

Kernel pointers

System Hardening

Fig. 8

The Inevitability of Failure

The Flawed Assumption of Security in Modern Computing Environments

Fig. 9

Mandatory security

Trusted / protected path

Assurance

Linux Security Modules

READ LSM Hook

LSM Module

SELinux

Generalized MAC

Very fine-grained

Policy-flexible

Simplified Mandatory Access Control Kernel (SMACK)

Simple label-based MAC

Policy is written as triples:

subject object [–rwxa]

TOMOYO

Path-based MAC scheme

Automatic real-time policy generation

Policy applied to trees of process invocation

AppArmor

Pathname access control scheme

Security usability via familiar abstractions

Extending MAC

Netlabel

Secmark

NFSv4

sVirt

Audit

Required for certification

Monitor syscall, LSM & misc. security events

Actually quite useful

Integrity & Platform Security

TPM

IMA / EVM

TXT

VT-d

Anti Malware

Best done in userland

... but, file scanning still desired

fsnotify

fanotify

Seccomp

Extremely lightweight sandboxing

Reduces attack surface

Current Status

Meets extremely wide range of security goals

Security features now mainstream

Better equipped to address modern threats

Ongoing Challenges

Continued refinement & hardening

Multiple security models hindering adoption

Threats will continue to evolve

How to Help

Enable features

Report problems

Share knowledge

Fig. 10

Resources

Linux Kernel Security Wiki

LSM Mailing List

LWN Security page

Questions ?

Useful URLs

Kernel Security Wikihttp://security.wiki.kernel.org/

LSM Mailing Listhttp://vger.kernel.org/vger-lists.html#linux-security-module

LWN Security Pagehttp://lwn.net/Security/

“The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments”

http://csrc.nist.gov/nissc/1998/proceedings/paperF1.pdf

LSM Usenix Paperhttp://www.usenix.org/event/sec02/wright.html

Kernel Memory Protectionhttp://lwn.net/Articles/329787/

Linux Security Model Comparisonhttp://tomoyo.sourceforge.jp/wiki-e/?WhatIs#comparison

Useful URLs ...SELinux

http://selinuxproject.org/“Have You Driven an SELinux Lately?” (OLS paper on current state)

http://namei.org/ols-2008-selinux-paper.pdf“Anatomy of Fedora Kiosk Mode”

http://namei.org/presentations/fedora-kiosk-mode-foss-my-2008.pdf“SELinux Memory Protection Tests”

http://people.redhat.com/drepper/selinux-mem.html“A seatbelt for server software: SELinux blocks real-world exploits”

http://www.linuxworld.com/news/2008/022408-selinux.html

SMACKhttp://schaufler-ca.com/

AppArmorhttp://en.opensuse.org/Apparmor

TOMOYOhttp://tomoyo.sourceforge.jp/

“POSIX file capabilities: Parceling the power of root”http://www.ibm.com/developerworks/library/l-posixcap.html

“POSIX Access Control Lists on Linux”http://www.suse.de/~agruen/acl/linux-acls/online/

Useful URLs ..."Implementing Native NFSv4 ACLs in Linux"

http://lca2009.linux.org.au/slides/79.tar.gz

“Applying mount namespaces”http://www.ibm.com/developerworks/linux/library/l-mount-namespaces.html

“Disk encryption in Fedora: Past, present and future”http://is.gd/16012

“Limiting buffer overflows with ExecShield” (2005)http://www.redhat.com/magazine/009jul05/features/execshield/

“Linux Kernel Heap Tampering Detection”http://phrack.org/issues.html?issue=66&id=15#article

“System integrity in Linux”http://lwn.net/Articles/309441/

“Linux kernel integrity measurement using contextual inspection” (LKIM)http://portal.acm.org/citation.cfm?id=1314354.1314362

Intel TXT Sitehttp://www.intel.com/technology/security/

IBM TCPA Resources http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf

Invisible Things Labs http://theinvisiblethings.blogspot.com/

Image Credits

1. Bell Labs

2. Duke University Ad*Access

3. Hao Chen, David Wagner, and Drew Dean.

4. “nofeel” (flickr)

5. Unknown

6. Ian Lloyd (flickr)

7. James Morris

8. Steve Jurvetson (flickr)

9. Michael Scott (flickr)

10. Alfred T Palmer (LoC)

Recommended