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

Uploaded on

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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Linux Kernel Security Adapting 1960s Technology to st Meet 21 Century Threats James Morris Red Hat LinuxCon Boston 2010
  • 2. Fig. 1 History
  • 3. “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
  • 4. Fig. 2 Unix DAC
  • 5. DAC is “simple” and somewhat effective, but inadequate for modern environment: Does not protect against flawed or malicious code
  • 6. Fig. 3 (Actually, DAC is not simple)
  • 7. “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)
  • 8. Fig. 4 Enhanced DAC
  • 9. POSIX Capabilities (privileges) Access Control Lists (ACLs)
  • 10. Fig. 5 Namespaces
  • 11. Network Access Control Netfilter iptables ebtables Fig. 6
  • 12. Fig. 7 Cryptography
  • 13. Disk Encryption: dm-crypt ecryptfs Network Encryption: IPsec
  • 14. System Hardening ASLR NX GCC /dev/mem Kernel pointers Fig. 8
  • 15. Fig. 9 The Inevitability of Failure The Flawed Assumption of Security in Modern Computing Environments
  • 16. Mandatory security Trusted / protected path Assurance
  • 17. Linux Security Modules READ LSM Hook LSM Module
  • 18. SELinux Generalized MAC Very fine-grained Policy-flexible
  • 19. Simplified Mandatory Access Control Kernel (SMACK) Simple label-based MAC Policy is written as triples: subject object [–rwxa]
  • 20. TOMOYO Path-based MAC scheme Automatic real-time policy generation Policy applied to trees of process invocation
  • 21. AppArmor Pathname access control scheme Security usability via familiar abstractions
  • 22. Extending MAC Netlabel Secmark NFSv4 sVirt
  • 23. Audit Required for certification Monitor syscall, LSM & misc. security events Actually quite useful
  • 24. Integrity & Platform Security TPM IMA / EVM TXT VT-d
  • 25. Anti Malware Best done in userland ... but, file scanning still desired fsnotify fanotify
  • 26. Seccomp Extremely lightweight sandboxing Reduces attack surface
  • 27. Current Status Meets extremely wide range of security goals Security features now mainstream Better equipped to address modern threats
  • 28. Ongoing Challenges Continued refinement & hardening Multiple security models hindering adoption Threats will continue to evolve
  • 29. How to Help Enable features Report problems Share knowledge Fig. 10
  • 30. Resources Linux Kernel Security Wiki LSM Mailing List LWN Security page
  • 31. Questions ?
  • 32. Useful URLs Kernel Security Wiki LSM Mailing List LWN Security Page “The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments” LSM Usenix Paper Kernel Memory Protection Linux Security Model Comparison
  • 33. Useful URLs ... SELinux “Have You Driven an SELinux Lately?” (OLS paper on current state) “Anatomy of Fedora Kiosk Mode” “SELinux Memory Protection Tests” “A seatbelt for server software: SELinux blocks real-world exploits” SMACK AppArmor TOMOYO “POSIX file capabilities: Parceling the power of root” “POSIX Access Control Lists on Linux”
  • 34. Useful URLs ... "Implementing Native NFSv4 ACLs in Linux" “Applying mount namespaces” “Disk encryption in Fedora: Past, present and future” “Limiting buffer overflows with ExecShield” (2005) “Linux Kernel Heap Tampering Detection” “System integrity in Linux” “Linux kernel integrity measurement using contextual inspection” (LKIM) Intel TXT Site IBM TCPA Resources Invisible Things Labs
  • 35. 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)