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 Separate processes execute in separate memory space 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?

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 simple uniform in lowest layers of system Scheme should be psychologically acceptable

Terminology I: the entities 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? Read Write Familiar UNIX file system example: owner / group / world read / write / execute

Terminology II: the activities 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

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