A technical and historical presentation of Flask, an architecture for building secure operating systems kernels with an inclusion on the evolution of security in distributed environments and a quick overview of NSA's SELinux, a partial FLASK implementation.
Created as a team effort by Luis Espinal, Samantha Rassner and Sanjay Kumar.
1. Flask: Flux Advanced Security Kernel
ECE 579S, September, 2010
Worchester Polytechnic Institute
By
– Samantha Rassner
– Sanjay Kumar
– Luis Espinal
2. 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
3. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 3
4. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 4
5. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 5
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
Rassner, Kumar, Espinal. ECE 579S, 2010 6
7. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 7
8. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 8
9. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 9
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 10
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 11
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 12
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 19
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 20
21. 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
Rassner, Kumar, Espinal. ECE 579S, 2010 21
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
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
Rassner, Kumar, Espinal. ECE 579S, 2010
22
23. SELinux’s FLASK Architecture
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
Rassner, Kumar, Espinal. ECE 579S, 2010
23
24. LSM Architecture
From Wright et al “Linux Security Module Framework”, 2002
Rassner, Kumar, Espinal. ECE 579S, 2010
24
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
25
26. SELinux Kernel Architecture
From SELinux by Example, Caplan,
MacMillan, Mayer.
Prentice Hall, 2007 26
Rassner, 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
from Paul Moore’s “Trusted Computing with SELinux, RedHat 2008 Summit
Rassner, Kumar, Espinal. ECE 579S, 2010
27
28. 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
Rassner, Kumar, Espinal. ECE 579S, 2010
28
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
29
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
30
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-privilege
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
31
32. Type Enforcement Example (con’t)
allow user_t bin_t : file {read execute getattr};
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
32
33. /etc/passwd – standard Linux
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
33
34. /etc/passwd - SELinux
From SELinux by Example, Caplan, MacMillan, Mayer.
Prentice Hall, 2007
Rassner, Kumar, Espinal. ECE 579S, 2010
34
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
35
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
36