Advanced Operating Systems: Lecture 39 - Mr. Farhan Zaidi

CS703 ­ Advanced 
Operating Systems
By Mr. Farhan Zaidi

 

 


Lecture No. 
39


Overview of today’s lecture








Introduction to security and protection
Security issues
Policy vs Mechanism
Design principles for security
Security requirements
Security related terminology
Introduction to user authentication

Security & Protection




The purpose of a protection system is to prevent accidental or
intentional misuse of a system
Accidents






A program mistakenly deletes the root directory. No one can
login.
This sort of problem (relatively) easy to solve: just make the
likelihood small.

Malicious abuse:




A high school hacker breaks the password for user B of
accounting system A and transfers $3 million to his account.
This kind of problem very hard to completely eliminate (no
loopholes, can’t play on probabilities)

Security issues


Isolation





Authentication







When can process create or access a file?
Create or read/write to socket?
Make a specific system call?

Protection problem




Who can access the system. Involves proving identities to the system

Access control




Separate processes execute in separate memory space
Process can only manipulate allocated pages

Ensure that each object is accessed correctly and only by
those processes that are allowed to do so

Comparison between different operating systems




Compare protection models: which model supports least
privilege most effectively?
Which system best enforces its protection model?


Policy versus mechanism




A good way to look at the problem is to separate policy (what)
from mechanism (how)
A protection system is the mechanism to enforce a security
policy

roughly the same set of choices, no matter what policy

A security policy delineates what acceptable behavior and
unacceptable behavior.
Example security policies:
 that each user can only allocate 40MB of disk
 that no one but root can write to the password file
 that you can’t read my mail.







There is no perfect protection system


Very simple point, very easy to miss:

Protection can only increase the effort (“work factor”)
needed to do something bad. It cannot prevent it.
Even assuming a technically perfect system, there are always
the four Bs:
 Burglary: if you can’t break into my system, you can
always steal it (called “physical security”)
 Bribery: find whoever has access to what you want and
bribe them.
 Blackmail.
 Bludgeoning. Or just beat them until they tell you.





Design Principles for Security
System design should be public
Default should be no access
Check for current authority
Give each process least privilege possible
Protection mechanism should be

1.
2.
3.
4.
5.
-

1.

simple
uniform
in lowest layers of system
Scheme should be psychologically acceptable



Terminology I:  the entities


Principals – who is acting?






Objects – what is that principal acting on?





File
Network connection

Rights – what actions might you take?





User / Process Creator
Code Author

Read
Write

Familiar UNIX file system example:



owner / group / world
read / write / execute


Terminology II:  the activities


Authentication – who are you?




Authorization – what are you allowed to do?




identifying principals (users / programs)

determining what access users and programs have to
specific objects

Auditing – what happened


record what users and programs are doing for later
analysis / prosecution


User Authentication

Basic Principles. Authentication must identify:
1.
Something the user knows
2.
Something the user has
3.
Something the user is
This is done before user can use the system