安全操作系统中国科学技术大学计算机系陈香兰（ 0512 － 87161312 ）...

安全操作系统

中国科学技术大学计算机系陈香兰（ 0512－ 87161312）

xlanchen@ustc.edu.cn助教：裴建国Autumn 2008

第五章操作系统安全体系结构

安全体系结构的含义和类型计算机系统的安全体系结构设计的基本原则Flask 体系、 LSM 以及 Flask 在 LSM 中的应用权能体系

操作系统的设计问题

操作系统的测试

渗透测试和老虎队分析 Ethical hacking ：正面的黑客行动

打补丁可 / 不可

原因旧系统有了新的应用系统在设计时考虑不充分

构造安全操作系统时的安全体系结构应当如何？

安全体系结构的含义及类型

体系结构设计的主要任务各种不同角度的需求，可能有冲突需要折衷

计算机系统的安全体系结构，包括1. 详细描述系统中安全相关的所有方面2. 在一定的抽象层次上描述各个安全相关模块之间的

关系3. 提出指导设计的基本原理4. 提出开发过程的基本框架及对应于该框架体系的层

次结构

安全体系结构只是一个概要设计，而不能是系统功能的描述

要考虑到测评认证的有效性，充分参考可信计算机系统评估准则 TCSEC通用评估准则 CC

TCSEC 没有给出“安全体系结构”的定义，但对系统的体系结构和系统设计的文档资料提出了定性的要求，并且给出了顶层规范的定义

CC 也没有

美国国防部的目标安全体系（ DoD Goal Security Architecture ）把安全体系划分为 4 种类型抽象体系通用体系逻辑体系特殊体系

计算机系统的安全体系结构设计的基本原则

1. 从系统设计之初就考虑安全性2. 应尽量考虑未来可能面临的安全需求3. 隔离安全控制，并使其极小化4. 实施特权最小化5. 结构化安全相关功能6. 使安全相关的界面友好7. 不要让安全依赖于一些隐藏的东西

安全体系结构的含义和类型计算机系统的安全体系结构设计的基本原则Flask 体系、 LSM 以及 Flask 在 LSM 中的应用

FlaskLSMFlask 在 LSM 中的应用

权能体系

一、 Flask体系结构

Flask history

In 1992 & 1993, researchers at the NSA and SCC worked on the design and implementation of DTMach, an outgrowth of the TMach project and the LOCK project. DTMach integrated a generalization of type enforcement , a flexible

access control mechanism, into the Mach microkernel.

The DTMach project was continued in the DTOS project. The DTOS project improved upon the earlier design and imp

lementation work, yielding a prototype that was released to universities for research (e.g. Secure Transactional Resources, DX).

From： http://www.cs.utah.edu/flux/fluke/html/flask.html

After the DTOS project, a new joint effort was started by the NSA, SCC, and the University of Utah's Flux project to transfer the DTOS security architecture into the Fluke research OS.

During the integration, the architecture was enhanced to provide better support for dynamic security policies

It was named Flask. Flask: Flux Advanced Security Kernel

Flask was ported to: OSKit Security-Enhanced Linux

论文

Ray Spencer, et al., The flask security architecture: system support for diverse security policies, in Proceedings of the 8th conference on USENIX Security Symposium - Volume 8. 1999, USENIX Association: Washington, D.C.

FLASKFlux Advanced Security Kernel

The Flask Security Architecture: System Support for Diverse Security Policies

Ray Spencer Secure Computing CorporationStephen Smalley, Peter Loscocco National Security AgencyMike Hibler, David Andersen, Jay Lepreau University of Utah

参考了 Jim Stevens的 ppt

Outline

IntroductionPolicy FlexibilityInsufficiency of Popular MechanismsRelated WorkFlask Design and ImplementationResultsSummaryOther Flask object managersCurrent Status

Outline

Introduction

The notion of “security” in a system is defined in terms of its security policy

A wide range of security policies exist due to the diversity of computing environments

Operating systems must be flexible in support for security policies to accommodate the spectrum of security policies

Supporting policy flexibility is not as simple as just implementing multiple policies

3 Requirements of Policy FlexibilitySupport fine-grained access controls on low-level objectsPropagate access rights according to security policyDeal with changes in policy over time, including

revoking previously granted permissions

Earlier systems provided some mechanisms to implement policy flexibility Previous systems failed to address all three requirements at once

This paper describes Flask architecture and a microkernel based prototype to demonstrate that policy flexibility is feasible

Flask is based on the concept of mandatory access controls (MAC) Compare to discretionary access controls (DAC)

What’s aheadElaboration on meaning of policy flexibilityDiscussion of two popular mechanisms that limit policy

flexibilityFlask architecture overview and prototypeEvaluation of Flask prototype

Outline

Policy Flexibility

How?List all known security policies and define flexibility

through that list?Unrealistic

A better definition is needed!

It is more useful to define security policy flexibility by viewing the computer system as an abstract state machine with atomic state transformations

Total flexibility is achieved when security policy knows entire state of system and can affect all operations in the systemAllow/deny operationAtomically inject handler routines

It is possible to modify the existing security policy and to revoke any previously granted access.

Total flexibility is obviously not possible in a real system

A more realistic approach is to ask what subset of system state and operations are relevant to securityFlexibility of a practical system therefore depends on

how complete the set of control operations is and what portion of the state is available to the security policy

Granularity of the controlled operations affects the degree of flexibility because it impacts the granularity at which sharing can be controlled

A policy flexible system must be capable of supporting a wide variety of security policies.

Security policies may be classified byThe need to revoke previously granted accessThe type of input required to make access decisionsThe sensitivity of policy decisions to external factors like

history or environmentTransitivity of access decisions

Revocation is the most difficult characteristic to support

Security policy must deal with policy changes interleaved with execution of controlled operations

Interleaving must be atomic so any controlled operation has a consistent policy

Atomicity is difficult to achieve because access permissions tend to migrate throughout the system Example: Unix write permissions on a file are only checked when

the file is opened. The granted permission is cached in the file descriptor. Changing permissions only affects future open operations.

Migrated permissions are common in capabilities, access rights in page tables, open IPC connections, and other operations in progress

Must make sure entire system knows if a permission is revoked when policy changesComplicated and potentially expensiveMust identify relevant in-progress operations

Three ways to handle revocation for an in-progress operationAbort and return errorRestart operation and check permissionWait for operation to complete

Waiting is not safe because it does not enforce policy and can take an unbounded amount of time

Outline

Insufficiency of Popular Mechanisms

We will take a look at:Capability-Based Systems Intercepting Requests

Capability-Based Systems

Capabilities are transferable tokens that reference an object and access rightsA capability is an unforgable data structure maps access r

ights to objectscan be passed around stored in kernel memory so user can only modify it using an inte

rfacelike file descriptors

Example OS implementations are Hydra, KeyKOS, EROS, SCAP, ICAP, and Trusted Mach

Capability mechanisms are poorly suited to providing policy flexibility because they allow the holder of the capability to control the propagation of that capabilitySecurity policy MUST control propagation of access righ

ts to properly implement rules of security policyCannot trust the capability holders to implement policy

Hydra and KeyKOS had enhancements to limit propagation, but they were specific to certain policies and very complex

Intercepting Requests

A common approach to add security is to intercept service requests with an additional security layer

May be done in capability or non-capability based systems

Examples: Kernel Hypervisors (not VM!), SPIN, Lava, KeySAFE

Can work at kernel-level or user-level

LimitationsMust expose all abstractions and information flows that

the security policy wishes to controlRequires state to be exposed to avoid redundancies and to

make sure that policy enforcement mechanisms know what to do

Can only affect an operation as requests pass through the interface

Outline

Related Work

Security architecture of Flask is based on DTOS, which had similar goals. Had mechanisms that were policy independent, but not rich enough

to support some policies (particularly dynamic policies) Used Mach microkernel design to handle revocation of memory

permissions (could not handle other permissions)

Generalized Framework for Access Control (GFAC) Assumes all controlled operations are performed in same atomic

operation in which the policy is consulted Difficult to achieve in a practical system and primary obstacle that

Flask had to overcome

MulticsEffectively provided immediate revocation of memory pe

rmissions by invalidating segment descriptorsShows that this problem is not new

SpringHad a capability revocation method, but didn’t work for

migrated permissions

Outline

Flask Design and Implementation

Flask prototype is implemented in a microkernel-based multiserver OSMicrokernel isn’t essential thoughOnly requires a reference monitor

The base system is FlukeOriginally a capability-based systemModified to meet requirements of Flask architecture

consult

In operating systems architecture, a reference monitor is a tamperproof, always-invoked, and small enough to be fully-tested and analyzed module that controls all software access to data objects or devices (verifiable). The reference monitor verifies the nature of the request against a table of allowable access types for each process on the system.

Flask 体系结构图

Object manager – components that enforce security policy Security server – components that make security policy dec

isions

Primary Goal: Ensure that subsystems always have a consistent view of policy decisions regardless of how they are made and how they change over time

Secondary goals: application transparency, defense-in-depth, ease of assurance, and minimal performance overhead

Flask provides three primary elements for object managers: Interfaces for accessing security server decisions

Access – permission between two entitiesLabeling – specify security attributes of an objectPolyinstantiation – which member of a set of resources should b

e accessed for a particular request

Access vector cache (AVC) to cache decisions and minimize performance overhead

Registration service to receive notifications when policy changes

Object managers must define: a mechanism to assign labels to their objects a control policy, which specifies how security decisions

are actually used and enforcedhandling routines that are called when policy changes

Object Labeling

All objects controlled by the security policy are labeled with a set of security attributes, referred to as the security context

Flask provides two data types for labeling objects Security contexts – variable length strings that can be

interpreted by any application or user that understands the security policy, can contain whatever is needed by the security policy and is therefore flexible

SID – fixed size values used as references to security contexts, created for efficiency reasons (cheaper to pass around), security server maintains SID mappings

General Support Mechanisms

Client and Server Identification IPC calls require the client and server to be identified so t

he roles are known for a security decision

Caching security decisionsUse AVC to save security decisions because querying the

security server is expensive due to IPC and security computation

Coherence is provided by policy change handler routines

Polyinstantiation SupportSecurity server identifies which instantiation can be acces

sed by a client

Requesting and caching security decisions in Flask

Polyinstantiation in Flask

Microkernel-Specific Features

Binds an SID to each memory segment, which is the same SID of whatever object is stored in that memory, and allows Flask to leverage Fluke’s protection model

Associates a Flask permission with each memory access mode based on the SID of the address space and the memory segmentUses to verify that accesses to mapped memory are

allowed by security policy

Revocation Support

RequirementsAfter policy change, the object manager’s behavior must

reflect the changePolicy changes must complete in a timely manner

Three step protocolSecurity server notifies all object managers that may

previously been exposed to revoked permissionsObject manager updates its internal stateObject manager notifies the security server that the

update is complete

Sequence numbers are used to synchronize policy changes and policy decisions

Security Server

RequirementsProvide mapping from SIDs to security contextsAllocate SIDs for newly created objectsManage AVCs of object managers (with handler callback

s)Provide interface for changing policy (if needed)Cache computations on server side as well because comp

utations can get expensive

Distributed systems If in a homogeneous policy environment: the security

server of each node merely act as a local cache of the environment’s policy

to support heterogeneous policy environments, it is desirable for each node to have its own security server with a locally defined policy component, with some degree of coordination at a higher level.

Flask security server is defined through a combination of code and a policy databasePolicy database language can express many policiesAny security policy that can be expressed through the

prototype’s policy database language may be implemented simply by altering the policy database.

but some policy changes may require code changes or by completely replacing the security server.

BUT always do not require any changes to the object managers

The policies enforced by the prototype server were:Multi-level security

The policy logic for the multi-level security policy is largely defined through the security server code, aside from the labels themselves.

Type enforcement Identity-based access controlRole-based access control

The policy logic for the other subpolicies is primarily defined through the policy database language.

Outline

Flexibility of Flask Prototype

Three sources of potential inflexibilityRange of operations that system can controlLimitation of operations that may be invoked by the secu

rity policy (depends on object manager instances)Amount of state information available to security policy f

or making decisionsLimited to 2 SIDs per query in the prototype, cannot handle para

metersArchitecture does not limit this, but changing it may be a source

of reduced performance

Performance

Overhead for labeling is about 1% compared to Fluke

Table 2 presents measurements for IPC operations of various bit lengthsAll tests are in the AVC

Table 3 presents measurements for decision time when decision is stored in different locations

Table 2: IPC Time

Naive: same test as fluke, but with flaskClient identification: modified to use flask specific server-side IPC to obtain SID on every callClient impersonation: uses client side IPC to specify an effect SID for every call

Table 3: Security Decision Time

trivSS – computation is trivial, just communication overheadrealSS – combination of computation and communication

Revocation time is shown in Table 4.

It is the most expensive operation.

Shown with a varying number of connections.

Has overhead of stopping all threads in prototype. That is the majority of the time. Scales linearly with number of connections after that.

Although this is expensive, policy changes are relatively rare.

Table 4: Revocation Times

MacrobenchmarkGNU Build System (make,

gcc, ld)Compilation of about 8000

LOC of .c and .h filesAlso executed on FreeBSD

for comparision

Table 5: Execution Time

Table 6: Security Decision Resolution

Flask-FFS-PM – unmodified Fluke object managersMemfs – memory file system (to reduce page faults)

Hint – predetermined location in cacheCache – must find decision in cache

Invasiveness of Flask Code

Overall, Fluke components increased in size less than 8% (see Table 7)

Kernel increased by 19%57% of changes to process manager and 61% of

changes to kernel were “trivial”Only extended Fluke API with security

functionality, fully backwards compatible with Fluke

Outline

Summary

Paper provided a useable definition of policy flexibility Shows that pure capability based systems and intercepting

request based systems are inadequate for achieving policy flexibility

Paper described operating system security architecture capable of supporting a wide range of security policies

Demonstrated practicality of architecture with prototype microkernel-based system

Appendix A has examples for Flask based file server, network server, and process manager

Outline

Other Flask object managers

File ServerNetwork ServerProcess Manager

File Server

The Flask file server provides four types of controlled (labeled) objects: file systems, directories, files, and file description objects.

Since file systems, directories and files are persistent objects, their labels must also be persistent.

Figure 6: Labeling of persistent objects

Table 8: Permission requirements for relabeling a file.

Network Server

Table 9: Layered controls in the network protocol stack.

Process Manager

Outline

Current Status

NSA implemented a Linux Security Module (LSM) called SELinux It is an implementation of Flask It is in the mainline kernel Released in many distros including RHEL, Debian, etc. Often criticized for being overly complicated to set up and understan

TrustedBSD Part of this system is a port of SELinux extensions to FreeBSD TrustedDarwin is a port of TrustedBSD to the Darwin system Some components of TrustedBSD have spilled over into OS X, not s

ure if this includes Flask implementation

References

R. Spencer, S. Smalley, P. Loscocco, M. Hibler, D. Andersen, and J. Lepreau. The Flask Security Architecture: System Support for Diverse Security Policies. In Proceedings of the Eighth USENIX Security Symposium, pages 123-139, Aug. 1999.

http://www.cs.utah.edu/flux/fluke/html/flask.htmlhttp://www.nsa.gov/selinux

二、 LSM

SELinux & LSM

SELinux motivated the creation of LSM.Separate kernel from security features in order to mi

nimize the impact to kernel.LSM doesn’t provide any security but it adds securit

y fields to kernel and provides interfaces for managing these fields for maintaining security attributes.

论文

Outline

IntroductionDesign and ImplementationTesting and FunctionalityConclusions

Outline

Introduction

Security is a chronic and growing problemLinux systems do experience a large number of

software vulnerabilitiesAn important way to mitigate software

vulnerabilities is through effective use of access controls.DACNon-DAC

But there has been no real consensus on which is the one true access control model.

Because of this lack of consensus, there are many patches to the Linux kernel that provide enhanced access controls [6, 10, 11, 13, 16, 18, 23, 19, 31] but none of them are a standard part of the Linux kernel.

The Linux Security Modules (LSM) project seeks to solve this Tower of Babel quandry by providing a general purpose framework for security policy modules.This allows many different access control models to be i

mplemented as loadable kernel modules, enabling multiple threads of security policy engine development to proceed independently of the main Linux kernel.

A number of existing enhanced access control implementations have already been adapted to use the LSM framework, POSIX.1e capabilitiesSELinuxDomain and Type Enforcement (DTE)

Outline

The problem: Constrained Design Space

At the 2001 Linux Kernel Summit, the NSA presented their work on SELinux, an implementation of a flexible access control architecture in the Linux kernel.

Linus Torvalds appeared to accept that a general access control framework for the Linux kernel is needed.

However, given the many Linux kernel security projects, and Linus’ lack of expertise in sophisticated security policy, he preferred an approach that allowed security models to be implemented as loadable kernel modules. In fact, Linus’ response provided the seeds of the LSM design.

The design of LSM was constrained by the practical and technical concerns of both the Linux kernel developers and the various Linux security projects.

Linus Torvalds specified that the security framework must be: truly generic, where using a different security model is m

erely a matter of loading a different kernel module; conceptually simple, minimally invasive, and efficient; able to support the existing POSIX.1e capabilities logic a

s an optional security module.

The “LSM problem”

The “LSM problem” is to unify the functional needs of as many security projects as possible, while minimizing the impact on the Linux kernel.

LSM takes the approach of mediating access to the kernel’s internal objects: tasks, inodes, open files, etc., as shown in Figure 1.

Figure 1: LSM Hook Architecture

why LSM chose this approach?

? system call interposition: mediating system calls as they enter the kernel

? device mediation: mediating at access to physical devices Reason: information critical to sound security policy decisio

ns is not available at those points At the system call interface, userspace data, such as a path name, has

yet to be translated to the kernel object it represents, such as an inode. Thus, system call interpostion is both inefficient and prone to time-of-check-to-time-of-use (TOCTTOU) races

At the device interface, some other critical information (such as the path name of the file to be accessed) has been thrown away.

In between is where the full context of an access request can be seen, and where a fully informed access control decision can be made.

Figure 2: Permissive LSM hook.

Implementation

Implementation OverviewTask HooksProgram Loading HooksIPC HooksFilesystem HooksNetwork HooksOther Hooks

Design and Implementation Overview

The LSM kernel patch modifies the kernel in five primary Ways adds opaque security fields to certain kernel data structur

es inserts calls to security hook functions at various points

within the kernel code adds a generic security system callprovides functions to allow kernel modules to register an

d unregister themselves as security modules, moves most of the capabilities logic into an optional secu

rity module

Opaque Security Fields

The opaque security fields are void* pointers, which enable security modules to associate security information with kernel objects.

Table 1

Table 1: Kernel data structures modified by the LSM kernel patchand the corresponding abstract objects.

The setting of these security fields and the management of the associated security data is handled by the security modules.

Calls to Security Hook Functions

Figure 3 shows the vfs_mkdir kernel function after the LSM kernel patch has been applied.

Caller

Callee

Registering Security Modules

全局变量： security_ops 提供 Callee 的接口定义

2.6.26 中

观察 2.6.26 中关于 security_operations 的定义

security_ops 的初始化

将 caller与具体的 callee相挂接

源码中的 security_initcall

register_security 只能用来注册第一个安全模块

mod_reg_security ，栈式

Task Hooks

task_struct structure

task_security_ops

2.6.26 security_operations 中 task 相关

2.6.26 security.h 中对各 task hook 调用点的封装定义

The LSM task hooks have full task life-cycle coverage. create() task hook

a task can spawn children?

alloc_security() task hookmanage the new task’s security field.

2.6.26 中

do_fork 在 copy_process 中，调用 security_task_create

CONFIG_SECURITY 时

否则

Hook调用点

Hook在这里被调用

初始化 security 域

Hook 调用点，用来设置 security 域

Hook 调用点的定义

Security域的具体内容取决于挂上来的 callee

When a task exits

kill() task hook the task can signal its parent?

Parent: wait() task hook the parent task can receive the child’s signal?

free_security() task hook Release the task’s security field.

任务在运行过程中可能需要修改某些属性。例如： setuid(2).

setuid() task hook.post_setuid() task hook.

为防止某些任务的（潜在）敏感信息被泄露， LSM 介入对其他任务状态的查询。getpgid() getscheduler()

Program Loading Hooks

The linux_binprm structure represents a new program being loaded during an execve(2).

binprm_security_ops

May to change privileges when a new program is executed.

Hooks are used to verify a task’s ability to load a new program and update the task’s security field.

添加的模糊项

execve(2) alloc_security() ：分配模糊域相关空间 set_security() ：设置模糊域

may be called multiple times during a single execve(2)

compute_creds() : set the new security attributes of a taskTypically, it will calculate the tasks new credentials based on bot

h its old credentials and the security information stored in the linux_binprm security field.

Once the new program is loaded, free_security() ：释放模糊域相关空间

观察 2.6.26 中 security 域的分配、释放和赋值

在 do_execve 中，分配

释放

在 prepare_binprm 中设置

关于 compute_creds

compute_creds 的调用点

调用点

以 a.out 为例

装载 a.out的程序

Filesystem Hooks

For file operations, three sets of hooks filesystem hooks, inode hooks, file hooks.

LSM adds a security field to each of the associated kernel data structures: super block, inode, file.

观察相应数据结构中的 security域定义

观察相关的 hook定义，及其使用

IPC Hooks

standard SysV IPC mechanisms: shared memory, semaphores, message queues.

ipc_security_ops

shm_security_ops, sem_security_ops, msg_queue_security_ops, msg_msg_security_ops.

观察 2.6.26中的相关 hook定义

Other Hooks

LSM provides two additional sets of hooks: module hooks and a set of top-level system hooks.Module hooks can be used to control the kernel

operations that create, initialize, and delete kernel modules.

System hooks can be used to control system operations, such as setting the system hostname, accessing I/O ports, and configuring process accounting.

Outline

Performance Impact

The performance cost of the LSM framework is critical to its acceptance

it was a major part of the debate at the Linux 2.5 developer’s summit that spawned LSM.

Microbenchmarks & MacrobenchmarksCompared a stock Linux kernel to one modified with the LSM patch, but with no modules loaded

microbenchmarks

LMBench

results 最坏情况下的开销：

6.2% for stat(),6.6% for open/close, 7.2% for file delete.

通常情况下的开销：often 0%, ranging up to 2%

macrobenchmarks

building the Linux kernel

even better: no measurable performance impact.

Security Impact

LSM provide some real security value ？？This can be viewed in two ways.

First, must not create new security holes and needs to be thorough and consistent in its coverage. a project from IBM

static and dynamic analysis of the LSM framework Second, must be general enough to support a variety of a

ccess control modelsSELinuxDTE LinuxLSM port of Openwall kernel patchPOSIX.1e capabilitiesLIDS (Linux Intrusion Detection System)

Outline

Conclusions

requirements: to meet two criteria: be relatively painless for people who don’t want it, be useful and effective for people who do want it.

LSM meets these criteria. The patch is relatively small, the performance data shows that the LSM patch imposes

nearly zero overhead. The broad suite of security products from around the

world that have been implemented for LSM shows that the LSM API is useful and effective for developing Linux security enhancements.

Flask 体系结构在 Linux LSM 中的应用

对照 FLASK体系结构

Thanks ！The end.

安全操作系统中国科学技术大学计算机系陈香兰（ 0512 － 87161312 ）...

Documents

vw golf 系列英国价格表

2015 - inu.ac.krchinese).docx · web view国语国文系,...

操作系统原理与设计 -...

计算机系信息处理实验室 lecture 12 i/o system...

0117401: operating system...

嵌入式操作系统陈香兰 xlanchen@ustc.edu.cn...

计算机系信息处理实验室 lecture 4 system...

对外投资合作国别（地区）指南 -...

嵌入式操作系统 -...

计算机系信息处理实验室 lecture 7 processes,...

计算机系信息处理实验室 lecture 3 system...

国際単位系（si）第...

中国八大菜系 ...

国际关系的决定性因素：国家利 ...

操作系统原理与设计 -...

计算机系信息处理实验室 lecture 9 memory...

操作系统原理与设计 -...

国际关系史（上） - bbs.pku.edu.cn ·...

第五课国际关系和

法国 alliance 公司系列产品

安全操作系统 中国科学技术大学计算机系 陈香兰（ 0512 － 87161312 ）...

安全操作系统中国科学技术大学计算机系陈香兰（ 0512 － 87161312 ）...