Building a secure operating system for linux
1 / 23

Chapter 9 - PowerPoint PPT Presentation

  • Uploaded on

Building a Secure Operating System for Linux. Chapter 9. Chapter Overview. Linux Security Modules History Implementation SeLinux Reference Monitor Protection State Labeling State Transition State Administration Trusted Programs Security Evaluation. Linux Security Modules.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Chapter 9' - farica

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Chapter overview
Chapter Overview

  • Linux Security Modules

    • History

    • Implementation

  • SeLinux

    • Reference Monitor

    • Protection State

    • Labeling State

    • Transition State

    • Administration

    • Trusted Programs

    • Security Evaluation

Linux security modules
Linux Security Modules

  • Reference Monitor System for the Linux kernel.

  • Consists of two parts:

    • Reference Monitor Interface

    • Reference Monitor Module (LSM)

      • Several LSM's have been implemented.

      • Have covered AppArmor

      • Will try to cover SELinux

Lsm history
LSM History

  • Lots of early security work on Linux:

    • Argus PitBull

    • LIDS

    • Subdomain (AppArmor)

    • RSBAC

    • GRSecurity

    • DTE for Linux

    • Medusa DS9

    • Open Wall

    • HP's initiative

    • Flask (SELinux)

Lsm history ii
LSM History (II)

  • Obviously, (2001) a reference monitor was necessary for Linux; everybody was reinventing the wheel! But:

    • Linus Torvalds was not a security expert, could not decide on an approach

    • There was no real agreement as to which was the “best” approach.

  • Result was a design basde on kernel modules with a single interface for all the necessary modules.

  • LSM framework

Lsm requirements
LSM Requirements:

  • The reference monitor must be truly generic, so that switching to a different security model was simply a matter of loading a different kernel module.

  • The interfaces must be “conceptually simple, minimally invasive, and efficient.”

  • Must support the POSIX.1e capabilities mechanism as an “optional security module”.

Design of the reference monitor
Design of the reference monitor

  • Formed union of all projects to date.

  • Restricted number of authorization queries to prevent redundant authorizations.

  • Manual design, source code analysis tools were used to verify completeness and consistency, finding six bugs.

  • Most of the interface had negligible performance impact except for the CIPSO implementation. Network security is now supported inoe of two ways:

    • Labeled IPSec

    • New implementation of CIPSO called Netlabel

Lsm history final details
LSM History, final details

  • LSM framework was officially added to Linux kernel in version 2.6.

  • SELinux and POSIX capabilities were included with the release of LSM

  • Novell bought the company that supported AppArmor, so AppArmor is also available.

Lsm implementation
LSM Implementation

  • LSM Framework implemetation has three parts:

    • Reference monitor interface definition

    • Reference monitor interface placement

    • Reference monitor implementation

Lsm reference monitor definition
LSM Reference Monitor definition

  • Specifies the way the kernel can invoke the LSM reference monitor.

  • The description is in the file include/linux/security.h in the kernel sources. It defines a structure security_operations with all the LSM function pointers. They are called LSM hooks.

  • 150 hoks for authorizations, plus other hooks for labels, label transitions. And label maintenance.

Lsm reference monitor placement
LSM Reference Monitor placement

  • Where to place the hook?

    • At the entrance to the system call?

    • What about TOCTTOU attacks?

    • What about the “open” system call?

  • The hooks were placed using in-line function declarations.

Lsm reference monitor implementation
LSM Reference Monitor Implementation

  • Each LSM reference monitor is different.

  • However, most security enhanced versions of Linux use the same hooks.

  • Exception is RSBAC

Selinux reference monitor
SELinux Reference Monitor

  • Two distinct processing steps.:

    • Convert input values from the LSM hooks into one or more authorization queries.

    • Check against SELinux protection system.

Selinux contexts1
SELinux Contexts

  • Previous diagram gave idea of user labels;; each context has permissions assigned to it.

  • There is also an MLS policy, but, though it allows read down, it only allows write level.

  • Both type labels and MLS labels are checked.

  • 20 different object data types, and many operations, including read, write, execute, create, ioctl, fcntl, extended attributes, ..

  • Over 1000 state labels.

  • Very complex administration!

Selinux labeling state
SELinux Labeling State

  • Files/objects are labeled (by default) based on their location in the file system, but file contexts can be used to override the defaults.

  • Labels are inherited. For files, the label of a file is inherited from the label of its parent directed, some processes may have permission to relabel them.

Selinux transition state
SELinux Transition State

  • Rather than SUID programs, a label transition is only allowed at execution; the transition only gives limited privileges; also, not all programs can run a transitioning prtogram.

  • Instead of gatekeepers, SELinux relies onprogrammers to keep program safe.

Selinux administration
SELinux Administration

  • Different kinds of policies:

    • Monolithic

    • Modular

  • Policy development:

    • Strict policy

    • Targeted (like AppArmor)

    • Reference Policy