Linux Security Module (LSM) Framework

By Hasari Tosun 11/30/2006

Overview

Goal: To create a security module for Linux kernel Motivation: 1) Learn Linux kernel, 2) learn kernel-level security • Why secured Operating System?

• Brief summary of traditional Linux access control (Discretionary Access Control) • Principle of least privilege • Linux Security Modules (LSM) Framework • Brief introduction to Security Enhanced Linux (SELinux) Module • Project: Simple Sandbox Security Module (sandbox) • Demo

Why secured Operating System?

•

Software threats and Internet

: –

Network connectivity: N

etwork connectivity, in particular, the Internet increased software threats.

–

Active content:

have capability of triggering actions automatically (PDF, MS Office, many others) –

Mobile code:

designed to be transported across a network for execution on remote hosts (JavaScript, ActiveX etc) • On March 3rd, 2003, a vulnerability in Sendmail affected many organizations worldwide. The problem was that an e-mail message with a carefully-crafted "from," "to," or "cc" field could give the sender complete (root) control over any machine running Sendmail.

• Buffer overflow • Sendmail is installed as root

Why secured Operating System?

•

Insider Threats

: Comes from local area network which represents even more serious risk (

Gartner research has estimated that 70% of security incident costs are due to insider breaches

) •

Complex Software

: Complex software may have defects that can be exploited by attackers.

Why secured Operating System?

• http://www.cert.org/stats/cert_stats.html

Incidents Reported 160000 140000 120000 100000 80000 60000 40000 20000 0 19 90 19 92 19 94 19 96 19 98

Year

20 00 20 02 Incidents Reported

Discretionary access control (DAC)

• Prior to Linux kernel 2.6, DAC was the only security framework for Linux. • In a DAC model, security decisions are based solely on user identity and ownership of the objects.

• No protection against malicious or flawed software.

• Each user has complete discretion over his/her own objects.

DAC

• Only two major categories of users: admin and other.

• Too much privilege.

• Unbounded privilege escalation

• •

DAC: Details

Each process is associated with some credentials, which binds the process to a specific user or a specific group .

The use of credentials requires support both in the process data structure and in the resource being protected.

uid,gid fuid, egid fsuid,fsgid groups suid,sgid

user and group real identifiers User and group effective identifiers User and group effective identifiers for file access Supplemental group identifiers user and group saved identifiers

DAC: Details

• • • • uid=0 is root, gid=0 is root group.

If uid=0, kernel bypasses the permission checks.

When a process is created, it always inherit the credentials of its parent.

Effective credentials can be modified using system calls;

setuid(), setresuid(), setfsuid() and setreuid()

Principle of least privilege

Grant just the minimum possible privileges to permit a legitimate

action: • Minimized privileged modules: Give a privilege to only the parts of the program needing it. • Minimize privileges granted • Minimize privileges’ time Programming Tips: • Break the program into separate parts so that only small and independent parts require special privileges.

• If different parts must run concurrently, use processes; Threads share their security privileges

Linux Security Modules (LSM) Framework

• At the Linux Kernel 2.5 Summit (2001), several different security projects were proposed for the kernel.

• These different approaches were often incompatible.

• Under guidance of Linus, a group was formed to create Linux Security Modules framework with following principles: – The Linux kernel still does its normal security checks.

– When kernel needs to decide if access should be granted, it also asks a security module whether or not the action is okay.

– An administrator should pick the security module he wants .

LSM Architecture

• The LSM framework was designed so that almost all of its hooks would be restrictive • An authoritative hook makes the absolute final decision: if the hook says a request should be granted, then it's granted no matter what. • A restrictive hook can only add additional restrictions; it can't grant new permissions. • Authoritative model is more flexible. But it requires many radical changes to the Linux kernel.

LSM Architecture

User space Kernel space Operation DAC context LSM Primary Security Module 0/ERR 0/ERR Execute operation Policy files (policy database)

LSM UML Diagram

Before critical Action Security_ops >action(defined in security.h)

LSM Architecture

• So, Five components added to kernel or modified: 1. An interface of security functions. 2. Inserts calls to security functions at various points within the kernel code.

3. Adding security fields to kernel object.

4. Providing functions to allow kernel modules to register and unregister themselves as security modules.

5. Move capabilities logic into an optional security module.

LSM Architecture: 1)Function interface

• security.h file has security_operations structure which defines security functions as function pointers.

• It defines a global variable: extern struct security_operations security_ops ; • security.h defines a set of static functions that corresponds to a each security call.

• For each static function x, it executes

security_ops->x().

Thus, kernel calls x and x calls registered function pointer.

LSM Architecture: 2) kernel security calls

• LSM inserts calls to security functions at critical points in the kernel code to perform access control. For example: – fork.c

: Task Create – namei.c

: Virtual File System Create • LSM inserts calls to security functions at critical points in the kernel code to manage the security fields. For example: – inode.c

: security_inode_alloc – – inode.c

fork.c

: security_inode_free : security_task_alloc – fork.c

: security_task_free

LSM Architecture: 3) security fields in kernel objects

• security fields (

void * security

) added to various kernel objects.

• The setting of security fields is handled by security modules.

• These fields are used by security modules for labeling.

task_struct linux_binprm Super_block inode sk_buff net_device Kern_ipc_perm Task (Process) Program File System Pipe, File, or Socket Network buffer Network device Semaphore, Shared Memory Segment, or Message Queue

LSM Architecture: 4) Module Registration

• The primary security module must register itself using

register_security

function in security.c

file. • It only register one module as primary module.

• The decision of module stacking is left to primary module: – If the secondary module fails to register using

register_security

, it needs to call mod_reg_security – This function call the primary function to decide about stacking.

int register_security(struct security_operations *ops) { if (verify(ops)) { } printk(KERN_DEBU G "%s could not verify security_operations structure.\n", __FUNCTION__); return -EINVAL; } if (security_ops != &dummy_security_ops) return -EAGAIN; security_ops = ops; return 0;

LSM Architecture: 5) process capabilities

• The name "capabilities" comes from the now defunct POSIX draft 1003.1e.

• These capabilities are a partitioning of the all powerful root privilege.

• A process has three sets of bitmaps called the inheritable(I), permitted(P), and effective(E) capabilities.

• Each capability is implemented as a bit in each of these bitmaps which is either set or unset. • The kernel will check the appropriate bit in the effective set of the process for privileged operation.

process capabilities

• • • • • • • • • • • • • • • • • • CAP_AUDIT_WRITE Allow to generate audit messages by writing in netlink sockets CAP_AUDIT_CONTROL Allow to control kernel auditing activities by means of netlink sockets CAP_CHOWN Ignore restrictions on file user and group ownership changes CAP_DAC_OVERRIDE Ignore file access permissions CAP_DAC_READ_SEARCH Ignore file/directory read and search permissions CAP_FOWNER Generally ignore permission checks on file ownership CAP_FSETID Ignore restrictions on setting the setuid and setgid flags for files CAP_KILL Bypass permission checks when generating signals CAP_SETGID Ignore restrictions on group's process credentials manipulations CAP_SETPCAP Allow capability manipulations on other processes CAP_SETUID Ignore restrictions on user's process credentials manipulations CAP_SYS_ADMIN Allow general system administration CAP_SYS_BOOT Allow use of reboot( ) CAP_SYS_CHROOT Allow use of chroot( ) CAP_SYS_PTRACE Allow use of ptrace( ) on every process CAP_SYS_RESOURCE Allow resource limits to be increased CAP_SYS_TIME Allow manipulation of system clock and real-time clock The full list is given in text book (p. 813)

Security Enhanced Linux (SELinux) Module

• Developed by National Security Agency (NSA) • The most comprehensive implementation of LSM.

• Most of SElinux became part of LSM framework. • SELinux is primary security module in Fedora distribution.

SELinux: Object Labeling

• Important objects in the OS are labelled; Processes, files, inodes, superblocks etc.

• Files persistently labelled via extended attributes.

• Labels are called security

contexts.

SELinux Architecture

Operation SELinux Module context LSM 0/ERR DAC 0/ERR Security Server selinuxfs Execute operation Policy files (policy database)

SELinux Concepts

• •

Identity

: each user and process has a unique identity on the system.

Roles –

Used to specify acceptable actions from a user. Each role has a set of privileges assigned to it

SELinux Concepts

• •

Type

: This refers to the privileges assigned to the object

Policy rules

:

allow sysadm_t shadow_t:file getattr;

SELinux: Code walk through

• Brief code walk-through for SELinux

Simple Sandbox Security Module (sandbox)

• Although a few security modules exists that are very comprehensive, including SELinux, they are hard to manage. • It is difficult for a system administrator to write a correct security policy. • So, I wrote a simple sandbox security module that jail programs to a certain directory during

inode_create

operation.

sandbox

•

Security rule

: defined in

/etc/sandbox

in format of

=.

Thus, program x can only issue

inode_create

in

directoryx

.

• Rules are read during initialization of the module.

• If new rules are added, the module needs to be restarted.

sandbox: Code walk-through

• Source code is defined in sandbox.c file.

• Can be downloaded from: sandbox.c

sandbox

• In order for it to run: – Capabilities module needs to be set to m (loadable module, not built-in module) during build process.

– Without capabilities module running, sandbox module can stack against SELinux module.

sandbox: DEMO

•

DEMO (Flash)

•

DEMO (AVI)

Recap & Future directions

• Traditional Linux access control is

uid

and

guid

• A multi-leveled security framework for modern operating system is a must.

• LSM provides a powerful interface to create security modules for the kernel.

• Sandbox module demonstrates how easy is to create a security module.

• Current security modules such as SELinux use labeling which is difficult for policy writer. Thus, a simple rule based security module is needed • A more flexible module-stacking feature must be provided to allow any number of security modules .

References

• http://www.cs.montana.edu/~tosun/ cs518/

Questions?