Advanced Operating Systems: Lecture 39 - Mr. Farhan Zaidi

Advanced Operating Systems - Lecture 39: Security and protection. This lecture will cover the following: introduction to security and protection; security issues; policy vs mechanism; design principles for security; security requirements; security related terminology; introduction to user authentication;...

CS703 ­ Advanced  Operating Systems

By Mr Farhan Zaidi

39

 Introduction to security and protection

 Security issues

 Policy vs Mechanism

 Design principles for security

 Security requirements

 Security related terminology

 Introduction to user authentication

 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)

 Isolation

 Separate processes execute in separate memory space

 Process can only manipulate allocated pages

 Authentication

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

 Access control

 When can process create or access a file?

 Create or read/write to socket?

 Make a specific system call?

 Protection problem

 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?

 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.

 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.

1. System design should be public

2. Default should be no access

3. Check for current authority

4. Give each process least privilege possible

5. Protection mechanism should be

- simple

- uniform

- in lowest layers of system

1. Scheme should be psychologically acceptable

 Principals – who is acting?

 User / Process Creator

 Code Author

 Objects – what is that principal acting on?

 File

 Network connection

 Rights – what actions might you take?

 Write

 owner / group / world

 Authentication – who are you?

 identifying principals (users / programs)

 Authorization – what are you allowed to do?

 determining what access users and programs have to specific objects

 Auditing – what happened

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

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