Download - 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
3Rassner, Kumar, Espinal. ECE 579S, 2010
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
4Rassner, Kumar, Espinal. ECE 579S, 2010
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
5Rassner, Kumar, Espinal. ECE 579S, 2010
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
6Rassner, Kumar, Espinal. ECE 579S, 2010
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
7Rassner, Kumar, Espinal. ECE 579S, 2010
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
8Rassner, Kumar, Espinal. ECE 579S, 2010
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
9Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
12
Flask Architecture
• Object Manager
– Enforcer of Security Policy
• Security Server
– Makes Security policy decisions
• Access Vector Cache
– Speeds up Policy decsions
Rassner, Kumar, Espinal. ECE 579S, 2010
13
Flask Architecture
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
17
Polyinstantiation
• Resource sharing among clients
• Multiple Instantiations of resource (Memebers)
• Distinct SIDs for each instantiation
• SELinux uses /tmp/resourceid as polyinstantiated resource
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
19
Security Server
• Makes Policy decisions for access
• Maps Security Context to SID
• Polyinstantiation Support
• Support Load/Unload of Policies
• Support Policy Revocation
Rassner, Kumar, Espinal. ECE 579S, 2010
20
Access Vector Cache
• Speeds up access to policy decision
• Cache of Security policies provided by Security Server
• Intercepts policy revocation requests
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
22
SELinux At A Glance
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
• 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
23
SELinux’s FLASK Architecture
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
Rassner, Kumar, Espinal. ECE 579S, 2010
24
LSM Architecture
From Wright et al “Linux Security Module Framework”, 2002
Rassner, Kumar, Espinal. ECE 579S, 2010
25
SELinux LSM Architecture
From Anatomy of Security-Enhanced Linux (SELinux)
Architecture and implementation
M. Tim Jones, Consultant Engineer, Emulex Corp. 2008
Rassner, Kumar, Espinal. ECE 579S, 2010
26
SELinux Kernel Architecture
From SELinux by Example, Caplan,
MacMillan, Mayer.
Prentice Hall, 2007Rassner, Kumar, Espinal. ECE 579S, 2010
27
SELinux Policies
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
• Policy Flexibility Via Extended Attributes
– Can be used to implement• Domain types
• RBAC
• Need-to-know categories
– Applicable to • Process
• File/Resource
• User
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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/
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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};
Rassner, Kumar, Espinal. ECE 579S, 2010
33
/etc/passwd – standard Linux
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
34
/etc/passwd - SELinux
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010
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
Rassner, Kumar, Espinal. ECE 579S, 2010