Lecture - Security and Protection
Lecture - Security and Protection
Operating Systems
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
• 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
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
6. 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)