security an advanced introductioncs9242/05/lectures/04-sec.pdf · security an advanced introduction...
TRANSCRIPT
![Page 1: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/1.jpg)
SecurityAn Advanced Introduction
Gernot Heiser
COMP9242 2005/S2 Week 4
cse/UNSW/NICTA
![Page 2: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/2.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
![Page 3: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/3.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
➜ ... if it has no data?
![Page 4: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/4.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
➜ ... if it has no data?➜ ... if it contains the payroll database?
![Page 5: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/5.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
➜ ... if it has no data?➜ ... if it contains the payroll database?➜ ... if it is on a machine in the foyer?
![Page 6: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/6.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
➜ ... if it has no data?➜ ... if it contains the payroll database?➜ ... if it is on a machine in the foyer?➜ ... if it is in a locked room?
![Page 7: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/7.jpg)
WHAT IS SECURITY?
EXAMPLE 1: DOS
• Single-user system with no access control
• Is it secure?
➜ ... if it has no data?➜ ... if it contains the payroll database?➜ ... if it is on a machine in the foyer?➜ ... if it is in a locked room?➜ ... if it is behind a firewall?
cse/UNSW/NICTA COMP9242 2005/S2 W4 P1
![Page 8: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/8.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
![Page 9: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/9.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?
![Page 10: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/10.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?
![Page 11: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/11.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?➜ ask a staff member to do it?
![Page 12: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/12.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?➜ ask a staff member to do it?➜ ask several staff members to do it?
![Page 13: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/13.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?➜ ask a staff member to do it?➜ ask several staff members to do it?➜ hire a security firm?
![Page 14: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/14.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?➜ ask a staff member to do it?➜ ask several staff members to do it?➜ hire a security firm?➜ hire several security firms?
![Page 15: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/15.jpg)
WHAT IS SECURITY?
EXAMPLE 1: B ANKING STORE ’S WEEKLY EARNINGS
• Is it secure to
➜ ask a random customer to do it?➜ ask many random customers to do it?➜ ask a staff member to do it?➜ ask several staff members to do it?➜ hire a security firm?➜ hire several security firms?
• Depends? On what?
cse/UNSW/NICTA COMP9242 2005/S2 W4 P2
![Page 16: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/16.jpg)
SECURE SYSTEM
• Requires a security policy
➜ specified allowed and disallowed states of a system
![Page 17: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/17.jpg)
SECURE SYSTEM
• Requires a security policy
➜ specified allowed and disallowed states of a system➜ system needs to ensure that no disallowed state is ever entered➜ need OS mechanisms to prevent transitions from allowed to disallowed states
![Page 18: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/18.jpg)
SECURE SYSTEM
• Requires a security policy
➜ specified allowed and disallowed states of a system➜ system needs to ensure that no disallowed state is ever entered➜ need OS mechanisms to prevent transitions from allowed to disallowed states
• Security policy needs to identify the assets to be secured
➜ for computer security, the assets are typically data
![Page 19: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/19.jpg)
SECURE SYSTEM
• Requires a security policy
➜ specified allowed and disallowed states of a system➜ system needs to ensure that no disallowed state is ever entered➜ need OS mechanisms to prevent transitions from allowed to disallowed states
• Security policy needs to identify the assets to be secured
➜ for computer security, the assets are typically data
• Perfect security is generally unachievable
➜ need to be aware of threads➜ need to understand what risks can be tolerated
cse/UNSW/NICTA COMP9242 2005/S2 W4 P3
![Page 20: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/20.jpg)
DATA SECURITY
THREE ASPECTS :
• Confidentiality: prevent theft of data
➜ concealing data from unauthorised agents➜ need-to-know principle
![Page 21: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/21.jpg)
DATA SECURITY
THREE ASPECTS :
• Confidentiality: prevent theft of data
➜ concealing data from unauthorised agents➜ need-to-know principle
• Integrity: prevent damage of data
➜ trustworthiness of data: data correctness➜ trustworthiness of origin of data: authentication
![Page 22: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/22.jpg)
DATA SECURITY
THREE ASPECTS :
• Confidentiality: prevent theft of data
➜ concealing data from unauthorised agents➜ need-to-know principle
• Integrity: prevent damage of data
➜ trustworthiness of data: data correctness➜ trustworthiness of origin of data: authentication
• Availability: prevent denial of service
➜ ensuring data is usable when needed
cse/UNSW/NICTA COMP9242 2005/S2 W4 P4
![Page 23: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/23.jpg)
THREATS
• A weakness is a potential for a security violation
• An attack is an attempt by the attacker to violate security
➜ generally implies exploiting a weakness
• A threat is a potential for an attack
![Page 24: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/24.jpg)
THREATS
• A weakness is a potential for a security violation
• An attack is an attempt by the attacker to violate security
➜ generally implies exploiting a weakness
• A threat is a potential for an attack
• There is never a shortage of attackers, hence in practical terms
➜ threat ⇒ attack➜ weakness ⇒ violation
cse/UNSW/NICTA COMP9242 2005/S2 W4 P5
![Page 25: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/25.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
![Page 26: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/26.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
![Page 27: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/27.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity
![Page 28: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/28.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity➜ delegation?
![Page 29: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/29.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity➜ delegation?
• Repudiation of origin
➜ false denial of being source➜ attack on integrity
![Page 30: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/30.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity➜ delegation?
• Repudiation of origin
➜ false denial of being source➜ attack on integrity
• Denial of receipt
➜ false denial of receiving➜ attack on availability and integrity
![Page 31: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/31.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity➜ delegation?
• Repudiation of origin
➜ false denial of being source➜ attack on integrity
• Denial of receipt
➜ false denial of receiving➜ attack on availability and integrity
• Delay
➜ temporarily inhibiting service➜ attack on availability
![Page 32: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/32.jpg)
THREATS
• Snooping
➜ disclosure of data➜ attack on confidentiality
• Modification/Alteration
➜ unauthorised change of data➜ attack on data integrity
• Masquerading/Spoofing
➜ one entity impersonating another➜ attack on authentication integrity➜ delegation?
• Repudiation of origin
➜ false denial of being source➜ attack on integrity
• Denial of receipt
➜ false denial of receiving➜ attack on availability and integrity
• Delay
➜ temporarily inhibiting service➜ attack on availability
• Denial of service
➜ permanently inhibiting service➜ attack on availability
cse/UNSW/NICTA COMP9242 2005/S2 W4 P6
![Page 33: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/33.jpg)
SECURITY POLICY
• Partitions system state into allowed and disallowed
• Ideally mathematical model
• In reality natural-language description
![Page 34: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/34.jpg)
SECURITY POLICY
• Partitions system state into allowed and disallowed
• Ideally mathematical model
• In reality natural-language description
? often imprecise, ambiguous, inconsistent, unenforceable
? Example: transactions over $10k require manager approval
➜ but transferring $10k into own account is no violation
cse/UNSW/NICTA COMP9242 2005/S2 W4 P7
![Page 35: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/35.jpg)
SECURITY MECHANISMS
• Used to enforce security policy
➜ computer access control (login authentication)➜ OS file access control system➜ controls implemented in tools
• Example:
➜ Policy: only accountant can access finance system➜ Mechanism: on un-networked computer in locked room with only one key
• A secure system provides mechanisms that ensure
➜ prevention➜ detection➜ recovery
of violations
cse/UNSW/NICTA COMP9242 2005/S2 W4 P8
![Page 36: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/36.jpg)
ASSUMPTIONS
• Security is always based on assumptions
➜ eg lock is secure, key holders are trustworthy
• Invalid assumptions void security!
![Page 37: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/37.jpg)
ASSUMPTIONS
• Security is always based on assumptions
➜ eg lock is secure, key holders are trustworthy
• Invalid assumptions void security!
• Problem: assumptions are often implicit and poorly understood
• Security assumptions must be
➜ clearly identified➜ evaluated for validity
cse/UNSW/NICTA COMP9242 2005/S2 W4 P9
![Page 38: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/38.jpg)
TRUST
• Systems always have trusted entities
➜ hardware, operating system, sysadmin...
• Totality of trusted entities is the trusted computing base (TCB)
• Assumed to be trustworthy !
cse/UNSW/NICTA COMP9242 2005/S2 W4 P10
![Page 39: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/39.jpg)
TRUSTED COMPUTING BASE
The totality of protection mechanisms within a computersystem — including hardware, firmware and software — thecombination of which is responsible for enforcing a securitypolicy.
A TCB consists of one or more components that togetherenforce a unified security policy over a product or system.
The ability of the TCB to correctly enforce a security policydepends solely on the mechanisms within the TCB and on thecorrect input by system administrative personnel or parametersrelated to the security policy. [Gol99]
cse/UNSW/NICTA COMP9242 2005/S2 W4 P11
![Page 40: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/40.jpg)
POTENTIALLY INVALID ASSUMPTIONS
• The security policy is unambiguous and consistent
• The mechanisms used to implement the policy are correctlydesigned
• The union of mechanisms implements the policy completely
• The mechanisms are correctly implemented
• The mechanisms are correctly installed and administered
cse/UNSW/NICTA COMP9242 2005/S2 W4 P12
![Page 41: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/41.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
![Page 42: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/42.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
? Specifications
➜ unambiguous description of system behaviour➜ can be formal or informal
![Page 43: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/43.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
? Specifications
➜ unambiguous description of system behaviour➜ can be formal or informal
? Design
➜ justification that it meets specification➜ mathematical translation of specification or compelling argument
![Page 44: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/44.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
? Specifications
➜ unambiguous description of system behaviour➜ can be formal or informal
? Design
➜ justification that it meets specification➜ mathematical translation of specification or compelling argument
? Implementation
➜ justification that it is consistent with the design➜ mathematical proof or rigorous testing➜ by implication must also satisfy specification
![Page 45: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/45.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
? Specifications
➜ unambiguous description of system behaviour➜ can be formal or informal
? Design
➜ justification that it meets specification➜ mathematical translation of specification or compelling argument
? Implementation
➜ justification that it is consistent with the design➜ mathematical proof or rigorous testing➜ by implication must also satisfy specification
? Operation and Maintenance
➜ justification that system is used as per assumptions in spec
![Page 46: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/46.jpg)
ASSURANCE
• Process for bolstering (substantiating or specifying) trust
? Specifications
➜ unambiguous description of system behaviour➜ can be formal or informal
? Design
➜ justification that it meets specification➜ mathematical translation of specification or compelling argument
? Implementation
➜ justification that it is consistent with the design➜ mathematical proof or rigorous testing➜ by implication must also satisfy specification
? Operation and Maintenance
➜ justification that system is used as per assumptions in spec
• Assurance does not guarantee correctness/security!cse/UNSW/NICTA COMP9242 2005/S2 W4 P13
![Page 47: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/47.jpg)
ASSURANCE : ESTABLISHED APPROACHES
US DOD ORANGE BOOK [DOD86]
• Defines security classes
➜ D: minimal protection➜ C1-2: discretionary access control➜ B1-3: mandatory access control➜ A1: verified design
• Systems can be certified to a certain class
➜ very costly, hence only practicable for big companies➜ most systems only certified C2 (not more than Unix-style security)
cse/UNSW/NICTA COMP9242 2005/S2 W4 P14
![Page 48: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/48.jpg)
ASSURANCE : ESTABLISHED APPROACHES
COMMON CRITERIA [NIS99]
• ISO standard, developed out of Orange Book
• Seven evaluation assurance levels (EALs)
➜ EAL1: functionally tested➜ EAL2: structurally tested➜ EAL3: methodically tested and checked➜ EAL4: methodically designed, tested and reviewed➜ EAL5: semiformally designed and tested➜ EAL6: semiformally verified design and tested➜ EAL7: formally verified design and tested
![Page 49: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/49.jpg)
ASSURANCE : ESTABLISHED APPROACHES
COMMON CRITERIA [NIS99]
• ISO standard, developed out of Orange Book
• Seven evaluation assurance levels (EALs)
➜ EAL1: functionally tested➜ EAL2: structurally tested➜ EAL3: methodically tested and checked➜ EAL4: methodically designed, tested and reviewed➜ EAL5: semiformally designed and tested➜ EAL6: semiformally verified design and tested➜ EAL7: formally verified design and tested
• Higher levels imply more thorough evaluation
➜ not necessarily better security➜ implementation not verified
cse/UNSW/NICTA COMP9242 2005/S2 W4 P15
![Page 50: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/50.jpg)
SUMMARY
• Computer security is complex➜ depends on many aspects of computer system
• Policy defines security, mechanisms enforce security
• Important to consider:➜ what are the assumptions about threats and trustworthiness➜ incorrect assumptions ⇒ no security!
• Security is never absolute➜ given enough resources, mechanisms can be defeated➜ important to understand limitations➜ inherent tradeoff between security and usability
• Human factors are important➜ people make mistakes➜ people may not understand security impact of actions➜ people may be less trustworthy than thought
cse/UNSW/NICTA COMP9242 2005/S2 W4 P16
![Page 51: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/51.jpg)
SECURITY POLICIES : 2 CATEGORIES
• Discretionary (user-controlled) policies
➜ e.g. a1 can read a2’s object only with a2’s permission➜ user decides about access
• Mandatory (system-controlled) policies
➜ e.g. certain users cannot ever access certain objects➜ no user can change this
cse/UNSW/NICTA COMP9242 2005/S2 W4 P17
![Page 52: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/52.jpg)
SECURITY POLICY MODELS
• Represent a whole class of security policies
• Most system-wide policies focus on confidentiality
➜ e.g. military-style multi-level security models➜ classical example is Bell-LaPadula model [BL76]➜ most other based on this
• Other cases:
? Chinese-wall policy focuses on conflict of interest
? Clark-Wilson model focuses on separation of duty
cse/UNSW/NICTA COMP9242 2005/S2 W4 P18
![Page 53: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/53.jpg)
BELL -LAPADULA MODEL
• Each object has a security classification L(a)
• Each agent has a security clearance L(o)
• Classifications and clearances from hierarchical security levels
➜ top secret > secret > confidential > unclassified
![Page 54: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/54.jpg)
BELL -LAPADULA MODEL
• Each object has a security classification L(a)
• Each agent has a security clearance L(o)
• Classifications and clearances from hierarchical security levels
➜ top secret > secret > confidential > unclassified
• Rule 1 (“no read up”):
➜ a can read o only if L(a) ≥ L(o)➜ standard confidentiality
![Page 55: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/55.jpg)
BELL -LAPADULA MODEL
• Each object has a security classification L(a)
• Each agent has a security clearance L(o)
• Classifications and clearances from hierarchical security levels
➜ top secret > secret > confidential > unclassified
• Rule 1 (“no read up”):
➜ a can read o only if L(a) ≥ L(o)➜ standard confidentiality
• Rule 2 (“* Property”):
➜ a can write o only if L(a) ≤ L(o)➜ prevents leakage (accidental or by conspiracy)
cse/UNSW/NICTA COMP9242 2005/S2 W4 P19
![Page 56: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/56.jpg)
BELL -LAPADULA MODEL EXTENSIONS
• Can combine with discretionary access rights (read/writepermissions on specific objects)
• Can add orthogonal security categories indicating types of data
➜ restrict access to relevant categories➜ Denning’s lattice model [Den76]
cse/UNSW/NICTA COMP9242 2005/S2 W4 P20
![Page 57: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/57.jpg)
SECURITY MECHANISMS
• Used to implement security policies
![Page 58: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/58.jpg)
SECURITY MECHANISMS
• Used to implement security policies
• Based on access control
? discretionary access control (DAC)
➜ users can change access to objects
? mandatory access control (MAC)
➜ access rights centrally controlled
cse/UNSW/NICTA COMP9242 2005/S2 W4 P21
![Page 59: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/59.jpg)
ACCESS RIGHTS
• Simple rights
? read, write, execute/invoke, send, receive...
• Meta rights
➜ copy (propagate a right to another agent)➜ own (change rights of an object or agent)
cse/UNSW/NICTA COMP9242 2005/S2 W4 P22
![Page 60: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/60.jpg)
ACCESS CONTROL MATRIX
ObjectsAgents S1 S2 O3 O4
S1 terminate wait, signal, readsend
S2 wait, signal, read, executeterminate write
S3 wait, signal,receive
S4 control execute write
Note: Agents are objects too!
cse/UNSW/NICTA COMP9242 2005/S2 W4 P23
![Page 61: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/61.jpg)
ACCESS MATRIX PROPERTIES
• Rows define agents’ protection domains
• Columns define objects’ accessibility
![Page 62: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/62.jpg)
ACCESS MATRIX PROPERTIES
• Rows define agents’ protection domains
• Columns define objects’ accessibility
• Dynamic data structure: frequent
➜ permanent changes (e.g. chmod)➜ temporary changes (e.g. setuid)
• Very sparse with many repeated entries
• Usually not stored explicitly.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P24
![Page 63: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/63.jpg)
ISSUES FOR PROTECTION SYSTEM DESIGN• Propagation of rights:
➜ Can agent grant access to another?
• Restriction of rights:
➜ Can agent propagate restricted rights?
• Revocation of rights:
➜ Can access, once granted, be revoked?
• Amplification of rights:
➜ Can unprivileged agent perform restricted operations?
• Determination of object accessibility:
➜ Which agents have access?➜ Is object accessible at all (garbage collection)?
• Determination of agent’s protection domain:
➜ Which objects are accessible?
cse/UNSW/NICTA COMP9242 2005/S2 W4 P25
![Page 64: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/64.jpg)
ACCESS MATRIX IMPLEMENTATION : ACL S
Represent column-wise: access control list (ACL):
• ACL associated with object.
➜ Propagation: meta-right (e.g., owner can chmod)➜ Restriction: meta-right➜ Revocation: meta-right➜ Amplification: protected-invocation right (e.g., setuid )➜ Accessibility: explicit in ACL➜ Protection domain: hard (if not impossible)
![Page 65: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/65.jpg)
ACCESS MATRIX IMPLEMENTATION : ACL S
Represent column-wise: access control list (ACL):
• ACL associated with object.
➜ Propagation: meta-right (e.g., owner can chmod)➜ Restriction: meta-right➜ Revocation: meta-right➜ Amplification: protected-invocation right (e.g., setuid )➜ Accessibility: explicit in ACL➜ Protection domain: hard (if not impossible)
• Usually condensed via domain classes (UNIX groups)
• Full ACLs used by Multics, Apollo Domain, Andrew FS, NT.
![Page 66: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/66.jpg)
ACCESS MATRIX IMPLEMENTATION : ACL S
Represent column-wise: access control list (ACL):
• ACL associated with object.
➜ Propagation: meta-right (e.g., owner can chmod)➜ Restriction: meta-right➜ Revocation: meta-right➜ Amplification: protected-invocation right (e.g., setuid )➜ Accessibility: explicit in ACL➜ Protection domain: hard (if not impossible)
• Usually condensed via domain classes (UNIX groups)
• Full ACLs used by Multics, Apollo Domain, Andrew FS, NT.
• Can have negative rights, to:
➜ reduce “window of vulnerability”,➜ simplify exclusion from groups.
![Page 67: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/67.jpg)
ACCESS MATRIX IMPLEMENTATION : ACL S
Represent column-wise: access control list (ACL):
• ACL associated with object.
➜ Propagation: meta-right (e.g., owner can chmod)➜ Restriction: meta-right➜ Revocation: meta-right➜ Amplification: protected-invocation right (e.g., setuid )➜ Accessibility: explicit in ACL➜ Protection domain: hard (if not impossible)
• Usually condensed via domain classes (UNIX groups)
• Full ACLs used by Multics, Apollo Domain, Andrew FS, NT.
• Can have negative rights, to:
➜ reduce “window of vulnerability”,➜ simplify exclusion from groups.
• Sometimes implicit (process hierarchy).
cse/UNSW/NICTA COMP9242 2005/S2 W4 P26
![Page 68: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/68.jpg)
ACCESS MATRIX IMPLEMENTATION : CAPABILITIES
Represent row-wise: capabilities
• Capability list associated with agent.
• Each capability confers a certain right to its holder.
➜ Propagation: copy capabilities between agents (how?)➜ Restriction: lesser rights require new (“derived”) capabilities➜ Revocation: requires invalidation of capabilities from all agents➜ Amplification: special invocation capability.➜ Accessibility: requires inspection of all capability lists (how?)➜ Protection domain: explicit in capability list.
![Page 69: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/69.jpg)
ACCESS MATRIX IMPLEMENTATION : CAPABILITIES
Represent row-wise: capabilities
• Capability list associated with agent.
• Each capability confers a certain right to its holder.
➜ Propagation: copy capabilities between agents (how?)➜ Restriction: lesser rights require new (“derived”) capabilities➜ Revocation: requires invalidation of capabilities from all agents➜ Amplification: special invocation capability.➜ Accessibility: requires inspection of all capability lists (how?)➜ Protection domain: explicit in capability list.
• Can have negative rights, to:
➜ reduce “window of vulnerability”,➜ simplify management of groups of capabilities.
• Successful commercial system: IBM System/38 et fils
cse/UNSW/NICTA COMP9242 2005/S2 W4 P27
![Page 70: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/70.jpg)
CAPABILITIES
• Main advantage of capabilities is the fine-grained access control:
➜ Easy to provide specific access to selected agents.
![Page 71: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/71.jpg)
CAPABILITIES
• Main advantage of capabilities is the fine-grained access control:
➜ Easy to provide specific access to selected agents.
• Capability presents prima facie evidence of the right to access:
➜ capability ⇒ object identifier (naming),➜ capability ⇒ (set of) access rights,
![Page 72: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/72.jpg)
CAPABILITIES
• Main advantage of capabilities is the fine-grained access control:
➜ Easy to provide specific access to selected agents.
• Capability presents prima facie evidence of the right to access:
➜ capability ⇒ object identifier (naming),➜ capability ⇒ (set of) access rights,⇒ Any representation must contain object ID and access rights.⇒ Any representation must protect capability from forgery.
![Page 73: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/73.jpg)
CAPABILITIES
• Main advantage of capabilities is the fine-grained access control:
➜ Easy to provide specific access to selected agents.
• Capability presents prima facie evidence of the right to access:
➜ capability ⇒ object identifier (naming),➜ capability ⇒ (set of) access rights,⇒ Any representation must contain object ID and access rights.⇒ Any representation must protect capability from forgery.
• How implemented and protected?
![Page 74: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/74.jpg)
CAPABILITIES
• Main advantage of capabilities is the fine-grained access control:
➜ Easy to provide specific access to selected agents.
• Capability presents prima facie evidence of the right to access:
➜ capability ⇒ object identifier (naming),➜ capability ⇒ (set of) access rights,⇒ Any representation must contain object ID and access rights.⇒ Any representation must protect capability from forgery.
• How implemented and protected?
➜ tagged (protected by hardware),➜ partitioned (protected by software),➜ sparse (protected by obscurity).
cse/UNSW/NICTA COMP9242 2005/S2 W4 P28
![Page 75: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/75.jpg)
TAGGED CAPABILITIES
• Tag bit(s) with every (group of) memory word(s):
? Tags identify capabilities
? Capabilities are used and copied like “normal” pointers
? Hardware checks permissions on dereferencing capability
? Modifications turn tags off
? Only privileged instructions (kernel) can turn tags on
![Page 76: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/76.jpg)
TAGGED CAPABILITIES
• Tag bit(s) with every (group of) memory word(s):
? Tags identify capabilities
? Capabilities are used and copied like “normal” pointers
? Hardware checks permissions on dereferencing capability
? Modifications turn tags off
? Only privileged instructions (kernel) can turn tags on
➜ Propagation easy.➜ Restriction requires kernel to make new capability.➜ Revocation virtually impossible (memory scan!)➜ Amplification possible (see below).➜ Accessibility impossible to determine.➜ Protection domain difficult to establish.
![Page 77: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/77.jpg)
TAGGED CAPABILITIES
• Tag bit(s) with every (group of) memory word(s):
? Tags identify capabilities
? Capabilities are used and copied like “normal” pointers
? Hardware checks permissions on dereferencing capability
? Modifications turn tags off
? Only privileged instructions (kernel) can turn tags on
➜ Propagation easy.➜ Restriction requires kernel to make new capability.➜ Revocation virtually impossible (memory scan!)➜ Amplification possible (see below).➜ Accessibility impossible to determine.➜ Protection domain difficult to establish.
• IBM System/38, AS/400, i-series; many historical systems.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P29
![Page 78: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/78.jpg)
PROTECTED PROCEDURE CALL (AS/400)
• AS/400 has a segmented memory architecture.
• Capabilities confer rights over segments.
• Capabilities can confer invocation rights.
• Each user has a profile, which is essentially a capability list.
• Capabilities can be of profile adoption type:
➜ On invocation, segment owner’s profile is added to caller’s protection domain.➜ Normal pointers can be dereferenced if the profile contains appropriate
capabilities.➜ On return, profile adoption is cancelled.➜ User can denote subset of their profile to be used in adoption (profile
propagation).
cse/UNSW/NICTA COMP9242 2005/S2 W4 P30
![Page 79: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/79.jpg)
TAGGED CAPABILITIES OUTSIDE RAM
• Disk has no tags.
• AS/400 page size is 4kB.
• Physical disk blocks are 520B, logical blocks 512B.
• Extra 64B per page store tag bits (among others).
➜ On page-out page must be scanned and all tags collected.➜ On page-in all tags must be reconsituted.➜ Significant processing overhead with all I/O.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P31
![Page 80: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/80.jpg)
TAGGED CAPABILITIES SUMMARY
• Secure through hardware protection.
• Convenient for applications (appear as “normal” pointers).
• Checked by hardware ⇒ fast validation.
• Hardware solution is not for everyone.
• Capability hardware is complex (and slow?)
• Separate mechanisms required for I/O and distribution.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P32
![Page 81: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/81.jpg)
PARTITIONED CAPABILITIES
• System maintains capability list (clist) with each process (in PCB).
? User code uses indirect references to capabilities (clist index).
? System validates access via clist when mapping any page.
![Page 82: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/82.jpg)
PARTITIONED CAPABILITIES
• System maintains capability list (clist) with each process (in PCB).
? User code uses indirect references to capabilities (clist index).
? System validates access via clist when mapping any page.
➜ Validation is implicit at page fault or explicit mapping time.➜ Propagation: system intervention to copy between clists.➜ Restriction: kernel to make new capability.➜ Revocation: kernel to remove cap from all (or specific) clists.➜ Accessibility can only be determined by scanning all clists.➜ Protection domain is explicitly represented in clist.
![Page 83: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/83.jpg)
PARTITIONED CAPABILITIES
• System maintains capability list (clist) with each process (in PCB).
? User code uses indirect references to capabilities (clist index).
? System validates access via clist when mapping any page.
➜ Validation is implicit at page fault or explicit mapping time.➜ Propagation: system intervention to copy between clists.➜ Restriction: kernel to make new capability.➜ Revocation: kernel to remove cap from all (or specific) clists.➜ Accessibility can only be determined by scanning all clists.➜ Protection domain is explicitly represented in clist.
• Hydra [CJ75], Mach [RTY+88], KeyKOS [BFF+92],Grasshopper [DdBF+94], EROS [SSF99] and many others.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P33
![Page 84: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/84.jpg)
PROPAGATING PARTITIONED CAPABILITIES (MACH):
• Capabilities can be propagated via IPC.
➀ User must insert capabilities (clist indices) into special field in message.➁ Kernel looks up clists and inserts representation of “real” capability
(marshaling).➂ Receiver’s kernel inserts capabilities into receiver’s clist.➃ Kernel replaces capability in message by clist index.
![Page 85: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/85.jpg)
PROPAGATING PARTITIONED CAPABILITIES (MACH):
• Capabilities can be propagated via IPC.
➀ User must insert capabilities (clist indices) into special field in message.➁ Kernel looks up clists and inserts representation of “real” capability
(marshaling).➂ Receiver’s kernel inserts capabilities into receiver’s clist.➃ Kernel replaces capability in message by clist index.
• Can be simplified if IPC is local.
• Amplification can be performed by schemes similar to AS/400.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P34
![Page 86: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/86.jpg)
PARTITIONED CAPABILITIES SUMMARY
• Secure through kernel protection.
• Validation at mapping time ⇒ apps use “normal” pointers.
• Fast validation (clist check is simple, validation cached by MMU).
• Propagation requires marshaling and kernel intervention.
• Reference counting possible to detect unaccessible objects.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P35
![Page 87: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/87.jpg)
SPARSE CAPABILITIES
Basic idea similar to encryption:
• Add bit-string to make valid capabilities a very small subset of thecapability space.
• Can be encrypted object info or something like a password.
• Capabilities are pure user-level objects, which can be passedaround like other data.
• Appropriate for user-level servers.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P36
![Page 88: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/88.jpg)
EXAMPLE : S IGNATURE CAPABILITIES
“First Migration Scheme ” [GL79], designed to allow migration oftagged capabilities in distributed systems.
Access rights SignatureObject ID
E(K,C)Key
Encrypted signature capability
f(O,A)
+ tamper proof via encryptionwith secret kernel key
+ can freely be passed around
– need to decrypt on eachvalidation
– users do not know which objectcapability refers to
• f : one-way function (secure hash), E: encryption function
cse/UNSW/NICTA COMP9242 2005/S2 W4 P37
![Page 89: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/89.jpg)
EXAMPLE : S IGNATURE CAPABILITIES
“Second Migration Scheme ” [GL79]
Access rightsObject ID
Access rights SignatureObject ID
E(K,C) Encrypted capability
Object ID visible, yet still tamper proof.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P38
![Page 90: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/90.jpg)
EXAMPLE : A MOEBA ’S CAPABILITIES
Port CheckObject ID Access rights
Object table
OID access check
Server
Appropriate for user-level servers [MT86].
cse/UNSW/NICTA COMP9242 2005/S2 W4 P39
![Page 91: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/91.jpg)
PROPERTIES OF AMOEBA CAPABILITIES
• Port identifies server.
➜ Kernel resolves server and caches server location.
• Port IDs are large (48-bit) sparse numbers.
➜ Knowledge implies send rights.
• Creator (“owner”) has all rights.
• Server uses OID to look up rights, checks fields to validate.
![Page 92: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/92.jpg)
PROPERTIES OF AMOEBA CAPABILITIES
• Port identifies server.
➜ Kernel resolves server and caches server location.
• Port IDs are large (48-bit) sparse numbers.
➜ Knowledge implies send rights.
• Creator (“owner”) has all rights.
• Server uses OID to look up rights, checks fields to validate.
➜ Validation done by user-level server when invoked.➜ Propagation easy, as capabilities are “normal” data.➜ Restriction requires server to make new capability.➜ Revocation done by server removing entry from object table.
But not very helpful if only one capability per access mode.➜ Amplification possible according to server policies.➜ Accessibility is impossible to determine.➜ Protection domain is impossible to determine.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P40
![Page 93: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/93.jpg)
AMOEBA RIGHTS RESTRICTION
Port Object ID Check11111111
one-way function
Port
New rights
New rights
+
New checkObject ID
➜ Used by server to derive lesser capabilities on request.➜ No need to store derived capability in object table.cse/UNSW/NICTA COMP9242 2005/S2 W4 P41
![Page 94: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/94.jpg)
IMPROVED VERSION (NOT IMPLEMENTED)
• Set of commuting one-way functions fi, one for each access modebit:fi(fj(x))) = fj(fi(x)).
• To remove access mode i, obtain new check field as:C′ = fi(C).
• Can be done by user without server intervention.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P42
![Page 95: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/95.jpg)
SERVER AUTHENTICATION : F-BOXES
• Hardware device “F-box” at each network connection
➜ When requesting messages for port G, F-box will only accept messagesdestined for port P = f(G), where f is a one-way function
➜ Server publishes P as port ID➜ Intruder who does not know G cannot access messages
• Scheme depends on physical security of F-boxes (or theirimplementation in the OS).
• Never been implemented (to my knowledge).
cse/UNSW/NICTA COMP9242 2005/S2 W4 P43
![Page 96: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/96.jpg)
PASSWORD CAPABILITIES
PasswordObject ID
Global object table
OID access password
• Used in the Monash Password Capability System [APW86],Opal [CLFL94], Mungi [HEV+98].
cse/UNSW/NICTA COMP9242 2005/S2 W4 P44
![Page 97: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/97.jpg)
PROPERTIES OF PASSWORD CAPABILITIES
• Passwords must be protected (eavesdropping, Trojan horses).
• Separate passwords for different rights (good idea to packagerights with caps).
• No encryption ⇒ easy to validate.
![Page 98: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/98.jpg)
PROPERTIES OF PASSWORD CAPABILITIES
• Passwords must be protected (eavesdropping, Trojan horses).
• Separate passwords for different rights (good idea to packagerights with caps).
• No encryption ⇒ easy to validate.
➜ Validation done by kernel on access or presentation and cached by MMU.➜ Propagation easy, as capabilities are “normal” data.➜ Restriction requires kernel to make new capability.➜ Revocation done by kernel removing entry from object table.➜ Amplification possible similar to AS/400.➜ Accessibility is impossible to determine.➜ Protection domain is known to kernel.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P45
![Page 99: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/99.jpg)
SPARSE CAPABILITIES SUMMARY
• Statistically secure (like encryption).
• Validation at mapping time ⇒ applications can use “normal”pointers.
• Validation may be slow, but kernel and MMU can cache.
• No kernel intervention required on most operations.
• Reference counting impossible to detect unaccessible objects.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P46
![Page 100: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/100.jpg)
CONFINEMENT
• Problem 1: Executing untrusted code
➜ you downloaded a game from the internet➜ how can you be sure it doesn’t steal all your data?
![Page 101: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/101.jpg)
CONFINEMENT
• Problem 1: Executing untrusted code
➜ you downloaded a game from the internet➜ how can you be sure it doesn’t steal all your data?
• Problem 2: Digital rights management (DRM)
➜ you own copyrighted material (e.g. movie)➜ you want to let others view it (for a fee)➜ how can you be sure the clients don’t make unauthorised copies?
![Page 102: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/102.jpg)
CONFINEMENT
• Problem 1: Executing untrusted code
➜ you downloaded a game from the internet➜ how can you be sure it doesn’t steal all your data?
• Problem 2: Digital rights management (DRM)
➜ you own copyrighted material (e.g. movie)➜ you want to let others view it (for a fee)➜ how can you be sure the clients don’t make unauthorised copies?
• Need to confine program (game, viewer) so it cannot leak data
• Cannot be done with most protection systems!
➜ not with UNIX or most other ACL-based systems➜ not with most tagged or sparse capability systems➜ multi-level security has some inherent confinement
but wouldn’t help for DRM
cse/UNSW/NICTA COMP9242 2005/S2 W4 P47
![Page 103: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/103.jpg)
CONFINEMENT
• Some protection models can confine in principle
➜ e.g. segregated caps system requires all caps to be presented explicitly➜ can instruct system not to accept any more caps from confined process➜ EROS has a formal proof of its confinement properties [SW00]
![Page 104: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/104.jpg)
CONFINEMENT
• Some protection models can confine in principle
➜ e.g. segregated caps system requires all caps to be presented explicitly➜ can instruct system not to accept any more caps from confined process➜ EROS has a formal proof of its confinement properties [SW00]
• In practice difficult to achieve confinement due to covert channels
cse/UNSW/NICTA COMP9242 2005/S2 W4 P48
![Page 105: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/105.jpg)
COVERT CHANNELS
• Information flow that is not controlled by a security mechanism
➜ Security requires absence of covert channels
![Page 106: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/106.jpg)
COVERT CHANNELS
• Information flow that is not controlled by a security mechanism
➜ Security requires absence of covert channels
• Two types of covert channels
? Covert storage channel uses an attribute of a shared resource
➜ typically some meta-data, like existence or accessibility of an object➜ global names create covert storage channels
![Page 107: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/107.jpg)
COVERT CHANNELS
• Information flow that is not controlled by a security mechanism
➜ Security requires absence of covert channels
• Two types of covert channels
? Covert storage channel uses an attribute of a shared resource
➜ typically some meta-data, like existence or accessibility of an object➜ global names create covert storage channels➜ in principle subject to access control➜ a sound access-control system should be free of covert channels
![Page 108: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/108.jpg)
COVERT CHANNELS
• Information flow that is not controlled by a security mechanism
➜ Security requires absence of covert channels
• Two types of covert channels
? Covert storage channel uses an attribute of a shared resource
➜ typically some meta-data, like existence or accessibility of an object➜ global names create covert storage channels➜ in principle subject to access control➜ a sound access-control system should be free of covert channels
? Covert timing channel uses a temporal ordering relationshipamong accesses to a shared resource
➜ outside access control system➜ difficult to reason about➜ difficult to prevent
cse/UNSW/NICTA COMP9242 2005/S2 W4 P49
![Page 109: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/109.jpg)
COVERT TIMING CHANNELS
• Can be created via a shared resource whose behaviour can bemonitored
➜ network bandwidth➜ CPU load➜ response time➜ locks
![Page 110: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/110.jpg)
COVERT TIMING CHANNELS
• Can be created via a shared resource whose behaviour can bemonitored
➜ network bandwidth➜ CPU load➜ response time➜ locks
• Require access to a time source
➜ real-time clock➜ anything else that allows unrelated processes to synchronise
![Page 111: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/111.jpg)
COVERT TIMING CHANNELS
• Can be created via a shared resource whose behaviour can bemonitored
➜ network bandwidth➜ CPU load➜ response time➜ locks
• Require access to a time source
➜ real-time clock➜ anything else that allows unrelated processes to synchronise
• Critical issue is bandwidth
? in practice the damage is limited if the bandwidth is low
➜ e.g. DRM doesn’t care about low-bandwidth channels
? beware of amplification (e.g. leaking a password capability)!
cse/UNSW/NICTA COMP9242 2005/S2 W4 P50
![Page 112: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/112.jpg)
DESIGN PRINCIPLES FOR SECURE SYSTEMS
• Least privilege
• Fail-safe defaults
• Economy of mechanism
• Complete mediation
• Open design
• Separation of Privilege
• Least common mechanisms
• Psychological acceptability
cse/UNSW/NICTA COMP9242 2005/S2 W4 P51
![Page 113: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/113.jpg)
LEAST PRIVILEGE
• Agent should only be given the minimal rights needed for task
? minimal protection domain (PD)
? PD determined by function, not identity
➜ Unix root is bad➜ role-based access control (RBAC) tries to address this
? rights added as needed, removed when no longer needed
cse/UNSW/NICTA COMP9242 2005/S2 W4 P52
![Page 114: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/114.jpg)
FAIL -SAFE DEFAULTS
• Default action is no access
? if action fails, system remains secure
? if security administrator forgets to add rule, system remainssecure
? “better safe than sorry”
cse/UNSW/NICTA COMP9242 2005/S2 W4 P53
![Page 115: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/115.jpg)
ECONOMY OF MECHANISM
• KISS principle of engineering
• Less code/features/stuff ⇒ less to get wrong!
? makes it easier to fix if something does go wrong
? complexity is the natural enemy of security
• Also applies to interfaces, interactions, protocols...
• Minimal trusted computing base!
cse/UNSW/NICTA COMP9242 2005/S2 W4 P54
![Page 116: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/116.jpg)
COMPLETE MEDIATION
• Check every access
![Page 117: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/117.jpg)
COMPLETE MEDIATION
• Check every access
? Violated in Unix file access:
➜ access rights checked at open()➜ access then enabled as long as file is open➜ ... even if access rights change
![Page 118: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/118.jpg)
COMPLETE MEDIATION
• Check every access
? Violated in Unix file access:
➜ access rights checked at open()➜ access then enabled as long as file is open➜ ... even if access rights change
? Also implies that any rights propagation must be controlled
➜ issue for tagged or sparse capability systems
![Page 119: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/119.jpg)
COMPLETE MEDIATION
• Check every access
? Violated in Unix file access:
➜ access rights checked at open()➜ access then enabled as long as file is open➜ ... even if access rights change
? Also implies that any rights propagation must be controlled
➜ issue for tagged or sparse capability systems
• In practice, this is in conflict with performance
? caching of buffers, file descriptors etc
? unacceptable performance in distributed systems
![Page 120: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/120.jpg)
COMPLETE MEDIATION
• Check every access
? Violated in Unix file access:
➜ access rights checked at open()➜ access then enabled as long as file is open➜ ... even if access rights change
? Also implies that any rights propagation must be controlled
➜ issue for tagged or sparse capability systems
• In practice, this is in conflict with performance
? caching of buffers, file descriptors etc
? unacceptable performance in distributed systems
• Should at least limit window of opportunity
➜ e.g. guarantee caches to be flushed after some fixed period
cse/UNSW/NICTA COMP9242 2005/S2 W4 P55
![Page 121: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/121.jpg)
OPEN DESIGN
• Security must not depend on secrecy of design or implementation
![Page 122: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/122.jpg)
OPEN DESIGN
• Security must not depend on secrecy of design or implementation
? the TCB must be open to scrutiny
? security by obscurity is poor security
➜ e.g. the US government’s Clipper initiative (’92)
![Page 123: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/123.jpg)
OPEN DESIGN
• Security must not depend on secrecy of design or implementation
? the TCB must be open to scrutiny
? security by obscurity is poor security
➜ e.g. the US government’s Clipper initiative (’92)
• note that this does not rule out passwords or secret keys
? but the way they are created/used requires careful cryptoanalysis
cse/UNSW/NICTA COMP9242 2005/S2 W4 P56
![Page 124: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/124.jpg)
SEPARATION OF PRIVILEGE
• Require combination of conditions to grant privilege
➜ e.g. user is in group wheel and knows the root password➜ closely related to least privilege
cse/UNSW/NICTA COMP9242 2005/S2 W4 P57
![Page 125: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/125.jpg)
LEAST COMMON MECHANISMS
• Avoid sharing mechanisms
? shared mechanism ⇒ shared channel
? potential covert channel
• Inherent conflict with other design imperatives
? simplicity ⇒ shared mechanisms
cse/UNSW/NICTA COMP9242 2005/S2 W4 P58
![Page 126: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/126.jpg)
PSYCHOLOGICAL ACCEPTABILITY
• Security mechanisms should not add to difficulty of use
? hide complexity introduced by security mechanisms
? ensure ease of installation, configuration, use
? systems are used by humans
![Page 127: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/127.jpg)
PSYCHOLOGICAL ACCEPTABILITY
• Security mechanisms should not add to difficulty of use
? hide complexity introduced by security mechanisms
? ensure ease of installation, configuration, use
? systems are used by humans
• Inherently problematic
? security inherently inhibits ease of use
? idea is to minimise impact
• Security-usability tradeoff is to a degree unavoidable
cse/UNSW/NICTA COMP9242 2005/S2 W4 P59
![Page 128: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/128.jpg)
REFERENCES
[APW86] Mark Anderson, Ronald Pose, and Chris S. Wallace. Apassword-capability system. The Comp. J., 29:1–8, 1986.
[Ber80] Viktors Berstis. Security and protection in the IBM System/38. In 7thSymp. Comp. Arch., pages 245–250. ACM/IEEE, May 1980.
[BFF+92] Alan C. Bromberger, A. Peri Frantz, William S. Frantz, Ann C. Hardy,Norman Hardy, Charles R. Landau, and Jonathan S. Shapiro. TheKeyKOS nanokernel architecture. In USENIX WS Microkernels & otherKernel Arch., pages 95–112, Seattle, WA, USA, Apr 1992.
[BL76] D.E. Bell and L.J. LaPadula. Secure computer system: Unifiedexposition and Multics interpretation. Technical Report MTR-2997,MITRE Corp., Mar 1976.
[CJ75] E. Cohen and D. Jefferson. Protection in the HYDRA operatingsystem. In 5th SOSP, pages 141–59, 1975.
[CLFL94] Jeffrey S. Chase, Henry M. Levy, Michael J. Feeley, and Edward D.Lazowska. Sharing and protection in a single-address-space operatingsystem. Trans. Comp. Syst., 12:271–307, 1994.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P60
![Page 129: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/129.jpg)
[DdBF+94] Alan Dearle, Rex di Bona, James Farrow, Frans Henskens, AndersLindstrom, and Francis Vaughan. Grasshopper: An orthogonallypersistent operating system. Comput. Syst., 7(3):289–312, 1994.
[Den76] Dorothy. E. Denning. A lattice model of secure information flow.CACM, 19:236–242, 1976.
[DoD86] US Department of Defence. Trusted Computer System EvaluationCriteria, 1986. DoD 5200.28-STD.
[GL79] V.D. Gligor and B.G. Lindsay. Object migration and authentication.Trans. Softw. Engin., 5:607–611, 1979.
[Gol99] Dieter Gollmann. Computer Security. Wiley, 1999.
[HEV+98] Gernot Heiser, Kevin Elphinstone, Jerry Vochteloo, Stephen Russell,and Jochen Liedtke. The Mungi single-address-space operatingsystem. Softw.: Pract. & Exp., 28(9):901–928, Jul 1998.
[MT86] Sape J. Mullender and Andrew S. Tanenbaum. The design of acapability-based distributed operating system. The Comp. J.,29:289–299, 1986.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P61
![Page 130: Security An Advanced Introductioncs9242/05/lectures/04-sec.pdf · Security An Advanced Introduction Gernot Heiser COMP9242 2005/S2 Week 4 cse/UNSW/NICTA](https://reader030.vdocuments.us/reader030/viewer/2022041006/5ead2b04ee922558b12e3ff0/html5/thumbnails/130.jpg)
[NIS99] US National Institute of Standards, http://csrc.nist.gov/cc/ .Common Criteria for IT Security Evaluation, 1999. ISO Standard15408.
[RTY+88] Richard Rashid, Avadis Tevanian, Jr., Michael Young, David Golub,Robert Baron, David Black, William J. Bolosky, and Jonathan Chew.Machine-independent virtual memory management for pageduniprocessor and multiprocessor architectures. Trans. Computers,C-37:896–908, 1988.
[Sol97] Frank G. Soltis. Inside the AS/400, Featuring the AS/400e series. 29thStreet Press, Loveland, CO, USA, 1997.
[SSF99] Jonathan S. Shapiro, Jonathan M. Smith, and David J. Farber. EROS:A fast capability system. In 17th SOSP, pages 170–185, Charleston,SC, USA, Dec 1999.
[SW00] Jonathan S. Shapiro and Samuel Weber. Verifying the EROSconfinement mechanism. In Symp. Security & Privacy, 2000.
cse/UNSW/NICTA COMP9242 2005/S2 W4 P62