Security Models

There are three classes of security model each with several subclasses:

1. Access Control Models

   • The Access Matrix

   • Take Grant Model

   • Bell LaPadula

2. Integrity Models

   • Biba

   • The Clack-Wilson

3. Information flow models

   • Non-interference model

   • Composition theories

Recommended Links

Softpanorama Recommended

Top articles

Sites

IT Security Publications

Modeling External Consistency of Automated Systems

Protection

Bell LaPadula Model

This discussion is taken from HongHai Shen's thesis.

The Bell-LaPadula Model (BLM), also called the multi-level model, was proposed by Bell and LaPadula for enforcing access control in government and military applications. In such applications, subjects and objects are often partitioned into different security levels. A subject can only access objects at certain levels determined by his security level. For instance, the following are two typical access specifications: ``Unclassified personnel cannot read data at confidential levels'' and ``Top-Secret data cannot be written into the files at unclassified levels''. This

mandatory access control, which, according to the United States Department of Defense Trusted Computer System Evaluation Criteria is ``a means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (e.g., clearance) of subjects to access information of such sensitivity".

The converse of mandatory access control is discretionary access control, which is defined as ``a means of restricting access to objects based on the identity of subject and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) to any other subject".

The Bell-LaPadula model supports mandatory access control by determining the access rights from the security levels associated with subjects and objects. It also supports discretionary access control by checking access rights from an access matrix. With respect to specification, we can regard the multi-level model as adding higher-level mechanisms to the matrix model. In addition to supporting arbitrary access specifications to the access matrix, the model groups protected objects according to different security labels and decides user privileges by their authorized security clearance levels (It is awkward, though not impossible, to specify this kind of access definition using the matrix model.).

More formally, each object is associated with a security level of the form (classification level, set of categories). Each subject is also associated with a maximum and current security level, which can be changed dynamically. The set of classification levels is ordered by a $<$ relationship. For instance, it can be the set top-secret, secret, confidential, unclassified, where

unclassified < confidential < secret < top-secret

A category is a set of names such as Nuclear and NATO. Security level A dominates B if and only if A's classification level > B's classification level, and A's category set contains B's. For instance,

top-secret, {Nuclear, NATO}

dominates

secret, {NATO}

because

top-secret > secret

and the set

{Nuclear, NATO}

contains

{NATO}

In the model, an access request (subj, obj, acc) is granted if and only if all of the following properties are satisfied:

simple security property (no read up): if acc is read, then level(subj) should dominate level(obj).

*-property (no write down): if acc = append, then level(obj) should dominate level(subj); if acc = write, then level(obj) should be equal to level(subj).

discretionary security property: the (subj, obj) cell in the matrix contains acc.

Like Multics, this model has the problems of hierarchical access control and does not always support the need to know principle except in rigid military situations.

l7

Security news
	Failure to scrub filename
		../.. leads to command execution
	Macro flaw in database query
		lets user add terms to query
	mod_ssl and Apache ssl bug
		asn.1 parse!

How do you know if a system is secure?
	What is "secure"?
	DoD is interested...
	DoD's concern:  secrecy

Bell-Lapadula model
	Often cited, seldom read
	Models military classification hierarchy
	specified as a lattice
		(partial ordering)
	levels - ordered; categories - subset
		 "dominates" 
	no "read up"
		can only read files if subject dominates or equal object
		i.e., cannot read informaiton more classified
	no "write down"
		called "*-property"
		Btw -- usual implementation is "write if equal" only
	called "mandatory access control" -- user cannot change own
	level or object's level

Discretionary access control
	Programmer can control
	Unix:  chmod
	Bell-Lapadula: matrix
	Multics:  ACL -- list of
		user,group	perm
		* == all	read,write,execute,append

No integrity in Bell-Lapadula!
	(ab)use "no write down"
	system routines at *low* confidentiality level

DoD wrote security spec with Bell-Lapadula at core
	"Orange Book"
	Part of "rainbow series"

Orange Book
	Specified security levels
	Specified features for each level
	Specified assurance
	Notion of TCB -- "trusted computing base"

Levels:
	D -- minimal protection
		default level
	C1 -- discretionary access
		authentication
		discretionary access control
		TCB protection
		TCB validation
		testing for assurance -- "no obvious ways"
			(2 B.S.-level people)
		documentation:
			user features
			admin
			test process for evaluators
			design document
	C2 -- controlled access
		C1+
		finer-grained access control
		no object reuse (clear memory)
		audit trail of object use
		more testing
	B1 -- labeled security protection
		DAC
		MAC
			security labels for subjects, objects
			labels protected by TCB
			label output
		Assurance
			testing: 2 B.S., 1 M.S.
			mandate separate address space
			more testing, audit (including object code)
				protect agains DoS!
			remove all flaws
			security policy model
			detailed design model
	B2 -- structured protection
		trusted path
		covert channels identified and measured
			timing channel
				burst of disk i/o
			storage channel
				fill disk
				file names in /tmp
		audit admin, operator actions
		assurance
			"carefully structured TCB"
			much more testing and review
			configuration management during development
			config management for specs
			major design document
	B3 -- Security domains
		exclude non-critical code from tcb
		very careful tcb design process
		assurance
			no design flaws, only a few implementation flaws
			even strong design documents
	A1 -- verified design
		no new features
		formal security model, formal top-level spec
		abstract definitions of TCB functions
		formal verification when possible
		formal analysis to find covert channels
		config management for everything, including diff tools
		testing -- 1 B.S., 2 M.S.

Networks
	Red Book -- "Trusted Network Interpretation"
	Explains network in terms of Orange Book

What do you do with this?
	Formal testing process
	Slow, expensive proces
	B1+ requires work at design time
	All but impossible to retrofit B2+ protection
	Tests *specific* versions, configuration of hardware, software

Typical designs
	Some look like Unix on steroids
		Add levels, ACLs
	Log in at level; files have attributes
	Floating label scheme
		Write to file -- it gets your level
		Read from file -- you get its level

Common Criteria
	Product of joint work with UK, Canada, Germany, France, Netherlands
	Separates features, assurance
	Building blocks:
		Audit
		Cryptographic Support
		Communications
		User Data Protection 
		Identification and Authentication
		Security Management
		Privacy
		Protection of the TOE Security Functions 
		Resource Utilisation
		TOE Access
		Trusted Path/Channels 
	Assurance:
		EAL1 - functionally tested
		EAL2 - structurally tested
		EAL3 - methodically tested and checked
		EAL4 - methodically designed, tested and reviewed
		EAL5 - semiformally designed and tested
		EAL6 - semiformally verified design and tested
		EAL7 - formally verified design and tested
	Security policy not built in

What are the problems?
	Slow testing process
		Hardware, software obsolete when test is done
	Configurations are weird
		No network?  
	Hard to accomodate minor changes

What are the *major* problems?
	Users don't want to buy them
	Doesn't match commercial security needs
	Model is obsolete

Orange Book based on model of 70's timesharing system
	What is the TCB?
		What was the TCB?
			Kernel
			root-invoked utilities
			compiler!
				Thompson story
	What is the role of Word?  Email?
	How do you read email?
		(windowing done ~1988)
	Classification level of aggregate?

Bell-Lapadula wrong commercially
	Need more integrity
	Secrecy model often too strict
	Doesn't accomodate networking well
	What would be good?
		Web hosting
			Multiple customers
			private data
			shared base
			virtual network statck

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019