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
Rassner, Kumar, Espinal. ECE 579S, 2010 2

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

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)


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


Flask Architecture
• Object Manager
– Enforcer of Security Policy
• Security Server
– Makes Security policy decisions
• Access Vector Cache
– Speeds up Policy decsions


Flask Architecture


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


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


Object Manager - Labeling

Client (SID –C)

Creates Client Object

Object Manager Security Server

Obj SID Obj SID Obj SID/ Context Map
SID

New SID New SID
Policy Logic
( SID,SID,Obj Type)
New SID Request
Label Rules

S
Enforcement Policy


Polyinstantiation
• Resource sharing among clients
• Multiple Instantiations of resource
(Memebers)
• Distinct SIDs for each instantiation
• SELinux uses /tmp/resourceid as
polyinstantiated resource


PolyInstantiation
Client (SID –C)

Creates Client Object

Object Manager

Obj SID
SID Poly Obj SID
Obj SID Security Server

Obj
SID/ Context Map
OBJ OBJ OBJ
SID SID SID

Mbr SID
New SID
Enforcement Mbr SID Req Policy
Policy Logic
( SID,SID,Obj Type)
Label Rules

S


Security Server
• Makes Policy decisions for access
• Maps Security Context to SID
• Polyinstantiation Support
• Support Load/Unload of Policies
• Support Policy Revocation


Access Vector Cache
• Speeds up access to policy decision
• Cache of Security policies provided by Security
Server
• Intercepts policy revocation requests


SELinux
• 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
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit


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

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

SELinux’s FLASK Architecture


23

LSM Architecture

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

24

SELinux LSM Architecture

From Anatomy of Security-Enhanced Linux (SELinux)
Architecture and implementation
M. Tim Jones, Consultant Engineer, Emulex Corp. 2008

25

SELinux Kernel Architecture

From SELinux by Example, Caplan,
MacMillan, Mayer.
Prentice Hall, 2007 26

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

27

SELinux – Trusted MAC/MLS
• 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
from Paul Moore’s “Trusted Computing with SELinux”, RedHat 2008 Summit

28

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

29

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/

30

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-privilege
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007

31

Type Enforcement Example (con’t)
allow user_t bin_t : file {read execute getattr};

Prentice Hall, 2007

32

/etc/passwd – standard Linux

Prentice Hall, 2007

33

/etc/passwd - SELinux

Prentice Hall, 2007
34

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

35

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

36

Flask: Flux Advanced Security Kernel

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Flask: Flux Advanced Security Kernel

Similaire à Flask: Flux Advanced Security Kernel (20)

Dernier

Dernier (20)

Flask: Flux Advanced Security Kernel