flask: flux advanced security kernel

Flask: Flux Advanced Security Kernel

ECE 579S, September, 2010

Worchester Polytechnic Institute

By

– Samantha Rassner

– Sanjay Kumar

– Luis Espinal

A Brief History… Early OS and Networking

1946 – ENIAC, the first digital computer

1961, 1963 – CTSS, the first multiple user mainframe and remote login

1964 – Multics, first multithreaded, mutliuser operating system

1965 – ARPANET and the first WAN connection made

2Rassner, Kumar, Espinal. ECE 579S, 2010

Unix and the Internet

1972 – Unix is released as a scaled down and portable Multics

1982 – IM PC is available to consumers

1986 – Mach Kernel is proposed to streamline and “secure” client-server architecture

1987, 1988 – T1 backbone begins, the Internet is opened to commercial traffic


Security? What Security?

1982 – The fist virus, the Elk Cloner

1988 – Morris Worm, first Internet attack, crashed 6k of 60k computers on ARPANET

1988, 1989 – Tmach and SDOS attempt to implement DoD secure systems

1991 – Linux released as open source, many developers use and improve the Linux kernel


And then…

1998 - NSA analyzes mainstream operating systems for security capability

1999 - NSA and U of Utah develop FLASK to address security “missing links” and create a platform for future secure systems

2003 - SELinux implements FLASK and is incorporated into Linux kernel 2.6


Evolution of Secure Distributed OS

• In the early days, security was a guard at the door

• User identification in place of user authentication

• Network closed to the public, only people using machines were the developers

• Developers often bypassed permission (logging in as root) to facilitate programming


Remember the Secure Design Principles…

• Least privilege

• Fail-safe defaults

• Economy of mechanism

• Complete mediation

• Open design

• Separation of privilege

• Least common mechanism

• Psychological acceptability


Adding Security After the Fact

• Bell-LaPadula security models often directly conflicted with operating system practices

• Network protocols designed for communication, not security

• Systems are as strong as their weakest link

– Internet security (circa 1980s)

• Scope of threats on a public Internet are very different than in the University and research centers


Modern Security Approach• User management – root is for admins only!

• Access Control lists

• Firewalls, antivirus

• IPSec, SSL, TLS

• AES, DES, WPA, etc.

• Still the same basic kernel…

– Needs to be more flexible to support least privilege

– Needs Mandatory Access Control in addition to Discretionary Access Control

• In 1999 NSA defined next-gen requirements


10

Flask

• OS Security Architecture

– Flexible security policies

• Flux advanced security kernel

– Prototyped on fluke OS

• Developed at University of Utah in 1999

• Implemented by NSA in Security Enhanced Linux ( SELinux)

Rassner, Kumar, Espinal. ECE 579S, 2010

11

Security Policy Requirements

• Fine grained access rights

– Enforcement of policy in system service components

• Controlling the propagation of access rights

– Consult policy on every access

• Revocation of access rights

– Prevent access after revocation of policy


12

Flask Architecture

• Object Manager

– Enforcer of Security Policy

• Security Server

– Makes Security policy decisions

• Access Vector Cache

– Speeds up Policy decsions


13

Flask Architecture


14

Object Manager

• Retrieve Access Interfaces

– Provides APIs to provide access to objects

• Labeling Interfaces

– Assign Security attributes to Objects

• Polyinstantiation Interfaces

– Provide member resources support


15

Object Manager - Labels

• Labels are security attributes

– Also called security context

• Security Context

– Variable length string

– Example: “identity:role:domain” in SELinux

• Security Identifier

– 32 bit value

– Maps to Security Context


16

Object Manager - Labeling

Creates Client Object

New SID

New SID Request

Enforcement Policy

Client (SID –C)

Object Manager

Obj SID

SID

Obj SID Obj

New SID

( SID,SID,Obj Type)

S

Security Server

SID/ Context Map

Policy Logic

Label Rules


17

Polyinstantiation

• Resource sharing among clients

• Multiple Instantiations of resource (Memebers)

• Distinct SIDs for each instantiation

• SELinux uses /tmp/resourceid as polyinstantiated resource


18

PolyInstantiation

Creates Client Object

Mbr SID

Enforcement Mbr SID Req Policy

Client (SID –C)

Object Manager

Obj SID

SID

Obj SID

Obj

New SID

( SID,SID,Obj Type)

S

Security Server

SID/ Context Map

Policy Logic

Label Rules

OBJ

SID

OBJ

SID

OBJ

SID

Poly Obj SID


19

Security Server

• Makes Policy decisions for access

• Maps Security Context to SID

• Polyinstantiation Support

• Support Load/Unload of Policies

• Support Policy Revocation


20

Access Vector Cache

• Speeds up access to policy decision

• Cache of Security policies provided by Security Server

• Intercepts policy revocation requests


21

SELinux

from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit

• An implementation of FLASK– Separates protection (enforcement) from security

(policy)

• SELinux MLS Policy Implements BLP– Implements a reliable, trusted MAC/MLS

• Via trusted channels and type enforcement

• Polyinstantiated/multi-level directories– Useful against inference attacks

– Example. access to /tmp is polyinstantiated according to domain’s security context


22

SELinux At A Glance


• Integrated in the mainline 2.6 series Linux

kernels

• Based on LSM Plugin Architecture

– LSM, a partial implementation of FLASK

• Integrated with existing DAC typical of Unix

systems

• Backwards Compatible

– Applications do not need to be compiled or written

specifically for SELinux


23

SELinux’s FLASK Architecture



24

LSM Architecture

From Wright et al “Linux Security Module Framework”, 2002


25

SELinux LSM Architecture

From Anatomy of Security-Enhanced Linux (SELinux)

Architecture and implementation

M. Tim Jones, Consultant Engineer, Emulex Corp. 2008


26

SELinux Kernel Architecture

From SELinux by Example, Caplan,

MacMillan, Mayer.

Prentice Hall, 2007Rassner, Kumar, Espinal. ECE 579S, 2010

27

SELinux Policies


• Policy Flexibility Via Extended Attributes

– Can be used to implement• Domain types

• RBAC

• Need-to-know categories

– Applicable to • Process

• File/Resource

• User


28

SELinux – Trusted MAC/MLS

from Paul Moore’s “Trusted Computing with SELinux”, RedHat 2008 Summit

• MLS supported in security contexts

– user:role:type:sensitivity[:category,...][-

sensitivity[:category,...]]

• Trusted Paths

– Client-Server Identification at IPC Level (as in

FLASK)

• Type Enforcement

– No access by default, no super user


29

SELinux – Type Enforcement

• Gives precedence to MAC over DAC– There is no access by default (no super user).

• Based on security context labeling

• Used for implementing least-privilege– Controls domain transition

• explicit who-can-access-what-and-how

• Allows variable granularity of policies controlling – Labeled file access

– Labeled networking

– Labeled printing


30

Type Enforcement Concepts

• Rights are based on labels in a security context, not on

process (owner/group) id.

• A security context contains labels

• A label applied to a process is a domain

• A label applied to a resource is a type

• Optionally, a role is an association of a domain to a type

for a given permission.

• Labels and roles defined under /etc/selinux/

from SELinux How To

http://www.linuxtopia.org/online_books/getting_started_with_SELinux/


31

Type Enforcement Example• Example:

– allow user_t bin_t : file {read execute getattr};

• user_t is a domain,a label applied to unprivileged processes

• bin_t is a type, a label for executables under /usr/bin

• This rule indicates unprivileged users can exec, read and get attributes from executable files under /usr/bin

• Used for implementing least-privilegeFrom SELinux by Example, Caplan, MacMillan, Mayer.

Prentice Hall, 2007


32

Type Enforcement Example (con’t)

From SELinux by Example, Caplan, MacMillan, Mayer.

Prentice Hall, 2007

allow user_t bin_t : file {read execute getattr};


33

/etc/passwd – standard Linux


Prentice Hall, 2007


34

/etc/passwd - SELinux


Prentice Hall, 2007


35

Notes

• LSM is a partial implementation of FLASK– Does not provide for access revocation of executing

transactions

– Requires support for extended attributes (not present in NFS)_

• Other Implementations (Path-based)– TOMOYO Linux

• Linux Kernel mainline version 2.6.30

– SMACK (Simplified Mandatory Access Control Kernel)

– AppArmor• Available with Ubuntu by default


36

References• SELinux by Example, Caplan, MacMillan, Mayer. Prentice Hall, 2007

• SELinux How To - http://www.linuxtopia.org/online_books/getting_started_with_SELinux/

• Paul Moore’s “Trusted Computing with SELinux”, RedHat 2008 Summit

– http://www.redhat.com/promo/summit/2008/downloads/pdf/Wednesday_245pm_Paul_Moore

_Whats_New_Infrastructure.pdf

• Anatomy of Security-Enhanced Linux (SELinux) Architecture and implementation, M. Tim Jones,

Consultant Engineer, Emulex Corp. 2008

– http://www.ibm.com/developerworks/linux/library/l-selinux/

• The Flask Security Architecture: System Support for Diverse Security Policies. Spencer et al.

Usenix 1999.

• The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing

Environments. Loscocco et al. 1998.

• Security is No Secret. Joab Jackson. Government Computer News. 2008.

• http://www.multicians.org/

• http://www.computerhistory.org/timeline/

• Issues in secure distributed operating system design., Wong, Raymond M., Digest of Papers -

IEEE Computer Society International Conference, Feb 1989. p.338-341

• Red Hat Enterprise Linux 4: Red Hat SELinux Guide,

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter-

0013.html

• A comparison of secure UNIX operating systems, Wong, R.M., Computer Security Applications

Conference, 1990., Proceedings of the Sixth Annual (0-8186-2105-2) 1990. p.333-333


http://www.ibm.com/developerworks/linux/library/l-selinux/




http://www.multicians.org/

http://www.computerhistory.org/timeline/

http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/selg-chapter-0013.html











flask: flux advanced security kernel

Technology

security systems

security capability1999

security missing links

weakest link internet

s scope of threats

discretionary access

mandatory access control

access control lists