**The Protection of Information in Computer Systems**
=====================================================

Security = techniques that control who may use or modify the computer or
the information contained in it.

# 1. THE BASIC
--------------

# Security risk/violation:
- Unauthorized information release:
- Unauthorized information modification
- Unauthorized denial of use

# Security techniques:
- protection: control the access of executing program to stored data.
- authentication: verify identity of the person making a request to computer
system

# Functional Levels of Information protection:
- Unprotected
- All or nothing: e.g. each users has his own private computer
- Controlled sharing: system defined which file to share by whom
- User-programmed sharing controls: user defines which data to share with whom
	(e.g Unix, Multics, Hydra...)
- Putting strings on information: like capability, i.e. maintaining some control
over the user of the information even *after* it has been released.

# some design principle
- KISS: keep it simple
	+ complicated system often results in unwanted access paths
- Fail-safe defaults: 
	+ i.e. the default situation is lack of access
- Complete mediation: 
	+ every access to every object must be checked for authority
- Open design
- Separation of privilege: (2 keys)
- Least privilege: 
	+ every program and every user of the system should operate using the
	least set of privilege necessary to complete the job
	--> hence, limiting the damage of accident or error
- least common mechanism
	+ hence reduce the number of potential information path between users
- Psychological acceptability:
	+ easy to use user interface

SOME EXAMPLES
-------------
# An Isolated Virtual Machine (Figure 1)
- descriptor-based protection
- 3 level of protection:
	1) Information being protected is the distinct program
		> e.g. program A cannot access memory address of program B
		> enforced by hardware
			+ every memory reference is checked against the base + bound
	2) The contents of descriptor register is protected
		> i.e, a user program cannot load the content of descriptor register
		> enforced by the privilege state bit in the processor 
		(like kernel vs. user mode)
	3) The privileged state bit
		> any attempt of a user program to turn this bit on will cause a 
		control transfer to the supervisor (kernel)

# Authentication mechanisms
- secrecy: i.e. passwords
	+ each users begins by typing a password that is presumably knowns only to
	that person
	+ disadvantage:
		> can be guessed 
		> can be leak, because the password must be exposed to be used
- unforgeability:
	+ user is given a key (or something similar) that is difficult to fabricate
- Weakness of Both secrecy and unforgeability:
	*One way* authentication, i.e, what if the computer system is compromised.

# Shared information
- ACL: 
	+ the guard holds a list of identifiers of authorized users
	+ check the list at the time access is requested (associate matching)
		> costly, not often used in high traffic application
- Capability
	+ users is given unforgeable tickets
	+ on access, users choose which tickets to present
	+ the guard just makes a simple comparison 
	(which is cheaper than a full scan of the access list)
	+ control the unforgeability and the passing of capability between user
==> ACL at human interface, capability in underlying hardware implementation

- def. principle: entity accountable for the activities of virtual processors.
(followed by a long examples from Fig. 2 to Fig. 4)

# 2. DESCRIPTOR-BASED PROTECTION SYSTEMS
----------------------------------------

# Separation of protection and addressing
(just for the presentation purpose, real implementation can combine this
into one.)
- Figure 5
- Protection: obtained by the descriptor register (containing r/w bit, seg-id) 
- Addressing: obtained by the descriptor table, each entry contains
	+ seg-id
	+ base
	+ bound

# 2.1. THE CAPABILITY SYSTEM**

*Basic Concepts*
----------------
- two kinds objects stored in memory
	+ protection descriptor values (which can be load to protection register)
	+ ordinary data values (cannot be load to protection register)
- any program can load value into the protection register, but only from 
memory location storing protection descriptor values.
(this memory location is tagged with extra bit)

- capability: memory location containing protection descriptor value
(with tag bit ON)
- See Figure 6.
	+ capabilities for each user is place in a catalog segment for that users.
	(e.g. catalog for Doe contains capability to shared math routine and 
	private database X)
	+ complexity in keep tracks of full range of object Doe may access:
		> it is not enough to look at initial catalog
		since segment A may contains some capabilities pointing to other segment
- because of the complexity in tracking capability, only useful for:
	+ simple, rarely changed, authorization pattern

*Dynamic authorization of sharing*
----------------------------------
- What if Doe want to share a segment X with Smith, i.e Doe wants to make Smith
knows about one of his (Doe's) capabilities.
- 2 ways:
	+ communication segments (N square)
	+ mailbox segments: Doe sends Smith a capability
	--> this message system system must be protected and reliable
- but there should be some previous communication external from computer system,
allowing recipient and sender to learn about each other's identity

*Benefit of Capability*
-----------------------
- efficiency: if the accessor can present a capability, the request is valid
- simplicity: true in this case, because they just intercept load/store
and use of hw to provide support.
- flexibility: user can create arbitrarily pattern of access authorization 

*Disadvantage of capability*
----------------------------
- revocation is a problem: once Doe gives a capability to Smith, and now Doe's
mind change, it is hard to revokes Smith access
- Propagation is a problem too:
	+ now Smith can duplicate Doe's capability (given to Smith) to any one else
	without permission of Doe
- review of access is a problem:
	+ say Doe want to know the list of all users able to access to his segment,
	the only way he can do is scanning all segments in the system and look for
	copies of corresponding capability. this process is time consuming

==> some work-around:
+ The copy bit in a capability, if this bit is OFF, recipient cannot make a 
copy of the capability ==> reduce flexibility
+ Restrict capability to be stored-loaded from some particular segments 
(capability-holding segment). This reduce the cost of reviewing, revoking, 
auditing the capability (since only a certain number of segment need be scanned)
+ Depth counter: limit the number of time a capability be duplicated

+ Enforce revocation through indirection
"
the basic capability mechanism be extended to include the possibility of forcing 
a capability to specify its target indirectly through a second location before 
reaching the actual object of interest. This second location would be an 
independently addressable recognizable object anyone with an appropriate 
capability for it could destroy the indirect object, revoking access to anyone 
else who had been given a capability for that indirect object. By constructing a 
separate indirect object for each different principal he shared an object with, 
the owner of the object could maintain the ability to revoke access 
independently for each principal"

# 2.2. Access Control List System
---------------------------------
- Example in Fig. 9, Fig. 10:
	+ each segment now associated with an access controller, which is protected
	+ an access to a segment lead to a check in the access controller for
		> the principal making the request
		> permission allowed
- access control can be extended to group protection (like that in Unix)

*Some problem and work around*
- every mem access require checking 
	==> solution: use shadow registers
		+ for the first look up, this shadow registers is filled
		+ subsequence accesses can use the shadows register directly
		(we see this in Multics, the linkage section, first time a trap,
		second time doesn't need a trap)
		TLB is another example
	Implication: revocation of a access control require the invalidation of
	the shadow registers
- allocation and search of access control list can be complex and slow
	==> solution
		+ constrain all access control list to three entries (Unix)
			> this simply the space allocation problem
		+ implement in software (in path to file system)
		
*Who change the ACL*
+ Self control: each access control associate with a user who may change it
	==> not very flexible. E.g.: if X is authorized to change the ACL, but X
	is ill, Y can not take place if needed
+ Hierarchical control:
	==> too powerful
	==> use and possible abuse of higher level authority is unchecked
+ Prescript approach (? see more in II.C.3)

*Discretionary and Non-discretionary control* (?)
- Discretionary control:
	+ user decides who can access objects that he creates
	+ some times, need to be prohibited
- When need non-discretionary?
- When need both?

# 2.3 Protecting object other than segments
- FIFO queue, Input/Output Device, Access Controller ...
- need to identify permit-able operations on each object
- then form a hierarchical control (like that in Fig 13)
	==> permission check may costly, because you may need to go all the way up

# 2.4 Protected objects and Domains (Section E)
- limitation of ACL and Capability:
	+ only those access restrictions provided by the standard system facilities
	can be enforced.
	+ users who borrow programs constructed by others: dangerous
	since borrowed programs can exercise all capabilities in the domain of
	the borrower.
- Solution: protected subsystems
	+ a collection of program and data segments that is *encapsulated* so that
		> other executing programs cannot read or write those segments
		> cannot disrupt the intended operation of the component programs,
		> can invoke the programs (of the protected subsystem) by calling
		designated entry points.
	+ operate in its own domain
	+ to change domain:
		+ in ACL system: change principal identifiers
			> add a new ENTER permission
			> add a *domain ID* in the access controller
			> a user wishing to provide a protected subsystem can:
				- add his principal identifier to every ACL of all objects
				of the subsystem
				- Add ENTER permission (for any other users who are allowed to
				use his subsystem) to the ACL of the initial procedure of his
				subsystem
		+ in capability system: acquire the set of capabilities of the new 
		domain (e.g.: we see this in Hydra)
			> capability C contains ENTER permission
			> GOTO (C), check for permission in C, control is transferred to the 
			procedure (whose address stored in C), and the processor
			switch on the READ permission bit of C, so that now the virtual
			processor can reach all objects addressed by capabilities stored in
			the procedure.
- some concern when switching domains:
	+ carefully control the passing of arguments
	+ (2 others more, which i can't understand) --> need to figure it out