Soma-notes - User contributions [en]

SystemsSec 2016W Lecture 23

2016-04-06T04:30:19Z

Nicholas Laws: /* Paper: Android Permissions Remystified */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
- Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
- Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final
• Anil tried to figure out exactly what problems people had with midterm
• People cited time pressure, not knowing what to study, and having issues writing “essays”
• Anil pointed out that for Q2 in particular, the textbook covered the elements of a secure OS at the end of every chapter, with specific examples.
• Anil reinforced the idea that PEOPLE NEED TO READ THE QUESTION, AND ANSWER EVERY COMPONENT.
• What are we supposed to get out of the papers?
o Learn the patterns in the papers
o If a paper says “x” is secure, you should be asking what the threat model is, where is the proof the attack/defense works like it is explained, how do you know?
o Trying to learn the proper way to think about security related problems
• Example question related to papers (something similar to this is likely to be present on the exam):
o For an attack paper, discuss x, y, z.
o For a defense paper, discuss x,y,z.
• People complained about vagueness and lack of structure, Anil reminded everyone that after you graduate, very few things are well defined or structured.
• Ask yourself what you have learned, and use it to answer the exam questions.
• Your success in learning is shown best via critical thinking.
• PLEASE READ THE QUESTIONS FULLY!!!
o And review your answer to make sure you address every single thing he asked.

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
• Basing a security system on reference monitors or raw cryptography is silly
o The concept of reference monitors is broken
o Cryptography is “fragile”
• Idea of diverse implementations so that 1 threat or attack does not compromise all systems
o Proof of Concept: Living Systems
• Computers CANNOT blindly trust anyone.
• Security is a trade off with functionality

SystemsSec 2016W Lecture 23

2016-04-06T04:29:31Z

Nicholas Laws: /* Anil: "Where the research is" */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
- Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
- Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final
• Anil tried to figure out exactly what problems people had with midterm
• People cited time pressure, not knowing what to study, and having issues writing “essays”
• Anil pointed out that for Q2 in particular, the textbook covered the elements of a secure OS at the end of every chapter, with specific examples.
• Anil reinforced the idea that PEOPLE NEED TO READ THE QUESTION, AND ANSWER EVERY COMPONENT.
• What are we supposed to get out of the papers?
o Learn the patterns in the papers
o If a paper says “x” is secure, you should be asking what the threat model is, where is the proof the attack/defense works like it is explained, how do you know?
o Trying to learn the proper way to think about security related problems
• Example question related to papers (something similar to this is likely to be present on the exam):
o For an attack paper, discuss x, y, z.
o For a defense paper, discuss x,y,z.
• People complained about vagueness and lack of structure, Anil reminded everyone that after you graduate, very few things are well defined or structured.
• Ask yourself what you have learned, and use it to answer the exam questions.
• Your success in learning is shown best via critical thinking.
• PLEASE READ THE QUESTIONS FULLY!!!
o And review your answer to make sure you address every single thing he asked.

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
- Placeholder
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
• Basing a security system on reference monitors or raw cryptography is silly
o The concept of reference monitors is broken
o Cryptography is “fragile”
• Idea of diverse implementations so that 1 threat or attack does not compromise all systems
o Proof of Concept: Living Systems
• Computers CANNOT blindly trust anyone.
• Security is a trade off with functionality

SystemsSec 2016W Lecture 23

2016-04-06T04:29:24Z

Nicholas Laws: /* Anil: "Where the research is" */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
- Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
- Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final
• Anil tried to figure out exactly what problems people had with midterm
• People cited time pressure, not knowing what to study, and having issues writing “essays”
• Anil pointed out that for Q2 in particular, the textbook covered the elements of a secure OS at the end of every chapter, with specific examples.
• Anil reinforced the idea that PEOPLE NEED TO READ THE QUESTION, AND ANSWER EVERY COMPONENT.
• What are we supposed to get out of the papers?
o Learn the patterns in the papers
o If a paper says “x” is secure, you should be asking what the threat model is, where is the proof the attack/defense works like it is explained, how do you know?
o Trying to learn the proper way to think about security related problems
• Example question related to papers (something similar to this is likely to be present on the exam):
o For an attack paper, discuss x, y, z.
o For a defense paper, discuss x,y,z.
• People complained about vagueness and lack of structure, Anil reminded everyone that after you graduate, very few things are well defined or structured.
• Ask yourself what you have learned, and use it to answer the exam questions.
• Your success in learning is shown best via critical thinking.
• PLEASE READ THE QUESTIONS FULLY!!!
o And review your answer to make sure you address every single thing he asked.

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
- Placeholder
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
- Placeholder
• Basing a security system on reference monitors or raw cryptography is silly
o The concept of reference monitors is broken
o Cryptography is “fragile”
• Idea of diverse implementations so that 1 threat or attack does not compromise all systems
o Proof of Concept: Living Systems
• Computers CANNOT blindly trust anyone.
• Security is a trade off with functionality

SystemsSec 2016W Lecture 23

2016-04-06T04:28:02Z

Nicholas Laws: /* Midterm Discussion */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
- Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
- Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final
• Anil tried to figure out exactly what problems people had with midterm
• People cited time pressure, not knowing what to study, and having issues writing “essays”
• Anil pointed out that for Q2 in particular, the textbook covered the elements of a secure OS at the end of every chapter, with specific examples.
• Anil reinforced the idea that PEOPLE NEED TO READ THE QUESTION, AND ANSWER EVERY COMPONENT.
• What are we supposed to get out of the papers?
o Learn the patterns in the papers
o If a paper says “x” is secure, you should be asking what the threat model is, where is the proof the attack/defense works like it is explained, how do you know?
o Trying to learn the proper way to think about security related problems
• Example question related to papers (something similar to this is likely to be present on the exam):
o For an attack paper, discuss x, y, z.
o For a defense paper, discuss x,y,z.
• People complained about vagueness and lack of structure, Anil reminded everyone that after you graduate, very few things are well defined or structured.
• Ask yourself what you have learned, and use it to answer the exam questions.
• Your success in learning is shown best via critical thinking.
• PLEASE READ THE QUESTIONS FULLY!!!
o And review your answer to make sure you address every single thing he asked.

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
- Placeholder
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
- Placeholder

SystemsSec 2016W Lecture 23

2016-04-06T04:27:10Z

Nicholas Laws: /* Midterm Discussion */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
 Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
 Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final
• Anil tried to figure out exactly what problems people had with midterm
• People cited time pressure, not knowing what to study, and having issues writing “essays”
• Anil pointed out that for Q2 in particular, the textbook covered the elements of a secure OS at the end of every chapter, with specific examples.
• Anil reinforced the idea that PEOPLE NEED TO READ THE QUESTION, AND ANSWER EVERY COMPONENT.
• What are we supposed to get out of the papers?
o Learn the patterns in the papers
o If a paper says “x” is secure, you should be asking what the threat model is, where is the proof the attack/defense works like it is explained, how do you know?
o Trying to learn the proper way to think about security related problems
• Example question related to papers (something similar to this is likely to be present on the exam):
o For an attack paper, discuss x, y, z.
o For a defense paper, discuss x,y,z.
• People complained about vagueness and lack of structure, Anil reminded everyone that after you graduate, very few things are well defined or structured.
• Ask yourself what you have learned, and use it to answer the exam questions.
• Your success in learning is shown best via critical thinking.
• PLEASE READ THE QUESTIONS FULLY!!!
o And review your answer to make sure you address every single thing he asked.

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
- Placeholder
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
- Placeholder

SystemsSec 2016W Lecture 23

2016-04-06T04:25:46Z

Nicholas Laws: /* Paper: Android Permissions Remystified */

==Topics and Readings==
*Boxify
**Michael Backes et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android]'' (USENIX Security 2015)
*Android Permissions
**Primal Wijesekera et al., ''[https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity]'' (USENIX Security 2015)

==Notes==

===Midterm Discussion===
• Midterms almost all marked
• Midterms will be returned on Thursday (April 7th), on average people did badly, we will discuss them in Thursday’s class
• Question 1 was answered best overall, Anil had issues believing people had actually used the system before when they failed to supply enough detail
• Question 2, most people just did not address all aspects of the question. Or argued for things that just were not true.
o Ex. Very few OS are verified, but lots of people claimed they were.
• Question 3 also had several problems, he was extremely lenient with what qualified as a system (nowhere did the question say it had to be a computer system)
• Example System: A Man carrying a suitcase full of cash
o Threat #1: Someone will steal the case
 Defense: Get a bodyguard
• Vulnerability: Guard could be bribed or could abandon you
o Threat #2: Hyperinflation reduces value of case contents to nothing
 Defense: Banks/Mints
• Vulnerability: Currency minting plates get stolen
• General Comment: FOLLOW THE FULL INSTRUCTIONS, BE SPECIFIC.
• Concerns of time pressure leading to Anil thinking of 4 questions for the final

===Paper: Boxify===

• Sandboxes applications
• It builds a reference monitor for individual applications
o This makes up for issues in the base Android monitor
• Paper discusses OS and Application Modifications:
o OS Modifications:
- Requires flashing the OS, not very accessible or easy for users
o Application Modifications:
- No boundary between reference monitor and application at base
• Full mediation and tamp reproofing not possible
• Uses a new(ish) Android mechanism for loading an application in a fully isolated process, then slowly implementing functionality/permissions using a reference monitor in a different process
o This grants (mostly) full mediation (misses Kernel Interface) and a decent amount of tamper proofing
• Android is based on system calls and intents
• Boxify shows several hallmarks of secure OS architecture; the reference monitor implementing a security policy
• Trusting only a small portion of the system to be secure, vs. trusting the entire system to be secure
• Is the chosen strategy a good one?
o Assuming Boxify is the very first app you install, sure.
• Boxify re-implements the entire Android permission model
• Ideally a reference monitor has little to no functionality
• Boxify “fails” safely, if it is forced to close the instances in the sandbox “starve” and die, since they only mechanism to interact with them (Boxify reference monitor) has been closed.

===Paper: Android Permissions Remystified===
- Placeholder
• Applications access private information more than the user expects
• Appls should stay within context, ex. A map application can have the user’s location, but only when the user is actively using it, not when it is in the background.
• Bad practice to just ask user for permission once on install/first run, contexts change.
• Some students found it surprising that 30% of the people from the user survery didn’t care how their info was used/misused
• One student expressed views that user studies were not trustworthy and that they refused to look a tthem.
• Why are user studies important?
o Security Engineers keep building tools users cannot use (or cannot use properly)
o They are a “club” to hit people with when they think they know the user’s needs better than the user does
o Studies used to prove that “X” is a good/bad idea
o Used to backup claims / results
• Do application developers want suers to properly understand how permissions work?
o No. They make more add revenue in the current system.

===Anil: "Where the research is"===
- Placeholder

SystemsSec 2016W Lecture 23

2016-04-06T04:25:20Z

Nicholas Laws: /* Paper: Boxify */

SystemsSec 2016W Lecture 23

2016-04-06T04:22:06Z

Nicholas Laws: /* Midterm Discussion */

SystemsSec 2016W Lecture 23

2016-04-05T22:20:25Z

Nicholas Laws:

Computer Systems Security (Winter 2016)

2016-04-05T22:09:30Z

Nicholas Laws: /* Lectures and Exams */

==Course Outline==

[[Computer Systems Security: Winter 2016 Course Outline|Here]] is the course outline.

==Hacking Opportunities==

The [[SystemsSec 2016W Hacking Opportunities|Hacking Opportunities]] page lists potential hacking opportunities that you can attempt for your hacking journal. If you attempt but do not successfully accomplish one of them, be sure to document what you tried. As you learn more, you may come back to them and try again.

==Resources==

===Readings===

* For the first part of the course we will be reading selections from Trent Jaeger's [http://www.morganclaypool.com/doi/abs/10.2200/S00126ED1V01Y200808SPT001 Operating Systems Security] textbook. You can download the PDF [http://www.morganclaypool.com.proxy.library.carleton.ca/doi/abs/10.2200/S00126ED1V01Y200808SPT001 through Carleton's library]. In the reading assignments this text will be referred to as "Jaeger".
* An excellent but dated text on browser security is Michal Zalewski's [https://code.google.com/p/browsersec/wiki/Main Browser Security Handbook].

===Other Courses===

* Dan Boneh ran an excellent course at Stanford in Spring 2015 on [https://crypto.stanford.edu/cs155/ Computer and Network Security]. This course has many interesting readings that we will not be covering. Also, the assignments are very good sources for hacking opportunities.
* The assignments from the Winter 2015 run of COMP 4108 [https://ccsl.carleton.ca/~dmccarney/COMP4108/ are available]. They are a reasonable start for several hacking opportunities.

==Lectures and Exams==

<table style="width: 100%;" border="1" cellpadding="4" cellspacing="0">
<tr valign="top">
<th>
Date
</th>
<th>
Topic
</th>
<th>
Readings
</th>
</tr>
<tr>
<td>
Jan. 7

</td>
<td>
[[SystemsSec 2016W Lecture 1|Introduction]]

</td>
<td>Jaeger, Chapter 1 (Introduction)</td></tr>
<tr>
<td>
Jan. 12

</td>
<td>
[[SystemsSec 2016W Lecture 2|Access Control, Security Hacking 101]]

</td>
<td>Jaeger, Chapter 2 (Access Control Fundamentals)</td></tr>
<tr>
<td>
Jan. 14

</td>
<td>
[[SystemsSec 2016W Lecture 3|Multics, UNIX, and Windows]]

</td>
<td>Jaeger, Chapter 3 (Multics) and Chapter 4 (UNIX & Windows) </td></tr>
<tr>
<td>
Jan. 19

</td>
<td>
[[SystemsSec 2016W Lecture 4|Secure OSs, theory and practice]]

</td>
<td>Jaeger, Chapter 6 (Security Kernels) and Chapter 7 (Securing Commercial Operating Systems)</td></tr>
<tr>
<td>
Jan. 21

</td>
<td>
[[SystemsSec 2016W Lecture 5|LSM, SELinux, & Capabilities]]

</td>
<td>Jaeger, Chapter 9 (LSM & SELinux) and Chapter 10 (Secure Capability Systems)</td></tr>
<tr>
<td>
Jan. 26

</td>
<td>
[[SystemsSec 2016W Lecture 6|Secure Virtual Machines, Systems Assurance]]

</td>
<td>Jaeger, Chapter 11 (Secure Virtual Machine Systems) and Chapter 12 (System Assurance)</td></tr>
<tr>
<td>
Jan. 28

</td>
<td>
[[SystemsSec 2016W Lecture 7|Lecture 7]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 2

</td>
<td>
[[SystemsSec 2016W Lecture 8|Lecture 8]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 4

</td>
<td>
[[SystemsSec 2016W Lecture 9|Defensive Security Technologies / Hacking Opportunities]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 9

</td>
<td>
[[SystemsSec 2016W Lecture 10|Security Research, Hashes, and Secure Protocols]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 11

</td>
<td>
[[SystemsSec 2016W Lecture 11|Modeling a potential attack/ Midterm FAQ]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 23

</td>
<td>
[[SystemsSec 2016W Lecture 12|Midterm Review]]

</td>
<td></td></tr>
<tr>
<td>
Feb. 25

</td>
<td>
Midterm (in class)

</td>
<td></td></tr>
<tr>
<td>
Mar. 1

</td>
<td>
[[SystemsSec 2016W Lecture 13|Buffer Overflow/Memory Corruption Attacks]]

</td>
<td>Aleph One (aka Elias Levy), [http://www.phrack.com/issues/49/14.html#article Smashing The Stack For Fun And Profit] (Phrack 49, 1996)</td></tr>
<tr>
<td>
Mar. 3

</td>
<td>
[[SystemsSec 2016W Lecture 14|Buffer Overflow/Memory Corruption Defenses]]

</td>
<td>
Wikipedia, [https://en.wikipedia.org/wiki/Buffer_overflow_protection Buffer Overflow Protection] 
Crispin Cowan et al., [https://www.usenix.org/legacy/publications/library/proceedings/sec98/cowan.html StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks] (USENIX Security, 1998)
</td>
</tr>
<tr>
<td>
Mar. 8

</td>
<td>
[[SystemsSec 2016W Lecture 15|Bypassing ASLR and Buffer Overflow Exploits using return-into-libc]]

</td>
<td>Hovav Shacham et al., [http://dx.doi.org/10.1145/1030083.1030124 On the effectiveness of address-space randomization] (ACM CCS, 2004) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1030124&ftid=285463&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)] 
Hovav Shachem [http://dx.doi.org/10.1145/1315245.1315313 The geometry of innocent flesh on the bone: return-into-libc without function calls (on the x86)] (ACM CCS 2007) [http://dl.acm.org.proxy.library.carleton.ca/ft_gateway.cfm?id=1315313&ftid=476749&dwn=1&CFID=588127386&CFTOKEN=74533951 (proxy)]</td></tr>
<tr>
<td>
Mar. 10

</td>
<td>
[[SystemsSec 2016W Lecture 16|Lecture 16]]

</td>
<td>Bellovin and Cheswick, [http://dx.doi.org/10.1109/35.312843 Network Firewalls] (IEEE Communications Magazine, 1994) [http://ieeexplore.ieee.org.proxy.library.carleton.ca/stamp/stamp.jsp?tp=&arnumber=312843 (proxy)]</td></tr>
<tr>
<td>
Mar. 15

</td>
<td>
[[SystemsSec 2016W Lecture 17|Lecture 17]]

</td>
<td>Dingledine, Mathewson, and Syverson, [https://www.usenix.org/legacy/events/sec04/tech/dingledine.html Tor: The Second-Generation Onion Router] (USENIX Security 2004) Albert Kwon et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kwon Circuit Fingerprinting Attacks: Passive Deanonymization of Tor Hidden Services] (USENIX Security 2015) (background)[https://www.torproject.org/about/overview.html.en Tor: Overview]</td></tr>
<tr>
<td>
Mar. 17

</td>
<td>
[[SystemsSec 2016W Lecture 18|Lecture 18]]

</td>
<td>Blase Ur et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ur Measuring Real-World Accuracies and Biases in Modeling Password Guessability] (USENIX Security 2015) 
Nikolaos Karapanos et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/karapanos Sound-Proof: Usable Two-Factor Authentication Based on Ambient Sound] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 22

</td>
<td>
[[SystemsSec 2016W Lecture 19|Lecture 19]]

</td>
<td>Giancarlo Pellegrino et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/pellegrino In the Compression Hornet’s Nest: A Security Study of Data Compression in Network Services] (USENIX Security 2015) Ramya Jayaram Masti et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/masti Thermal Covert Channels on Multi-core Platforms] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 24

</td>
<td>
[[SystemsSec 2016W Lecture 20|DDoS and Pinning]]

</td>
<td>Seyed K. Fayaz et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/fayaz Bohatei: Flexible and Elastic DDoS Defense] (USENIX Security 2015) Marten Oltrogge and Yasemin Acar, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 29

</td>
<td>
[[SystemsSec 2016W Lecture 21|Lecture 21]]

</td>
<td>David A. Ramos and Dawson Engler, [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/ramos Under-Constrained Symbolic Execution: Correctness Checking for Real Code] (USENIX Security 2015) Nav Jagpal et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/jagpal Trends and Lessons from Three Years Fighting Malicious Extensions] (USENIX Security 2015)</td></tr>
<tr>
<td>
Mar. 31

</td>
<td>
[[SystemsSec 2016W Lecture 22|Cookie Integrity and XSSI]]

</td>
<td>Xiaofeng Zheng et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/zheng Cookies Lack Integrity: Real-World Implications] (USENIX Security 2015) Sebastian Lekies et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/lekies The Unexpected Dangers of Dynamic JavaScript] (USENIX Security 2015)</td></tr>
<tr>
<td>
Apr. 5

</td>
<td>
[[SystemsSec 2016W Lecture 23|Boxify and Android Permissions]]

</td>
<td>Michael Backes et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/backes Boxify: Full-fledged App Sandboxing for Stock Android] (USENIX Security 2015) Primal Wijesekera et al., [https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/wijesekera Android Permissions Remystified: A Field Study on Contextual Integrity] (USENIX Security 2015)</td></tr>
<tr>
<td>
April 7

</td>
<td>
[[SystemsSec 2016W Lecture 24|Lecture 24]]

</td>
<td></td></tr>
<tr>
<td>
April 18, 10 AM-12 PM

</td>
<td>
Last-Minute Study Session

</td>
<td></td></tr>
<tr>
<td>
April 19, 9 AM

</td>
<td>
Final Exam

</td>
<td></td></tr>
</table>

==Lecture Notes Guidelines==

Part of your participation mark is doing notes for at least one of the lectures. Here are the guidelines for those notes.

The class TA Borke (BorkeObadaObieh at cmail.carleton.ca) will be handling course notes. Please contact her to schedule your class to take notes.

Borke or Anil will set you up with an account on this wiki. You'll enter your initial draft notes here and then work with Borke to make sure they are of sufficient quality. This may require a few rounds of revisions; however, if you follow the guidelines below it shouldn't be too bad.

You should plan on organizing your notes as follows:
* Organize them in at least the following sections: Topics & Readings and Notes.
* The Topics & Readings section lists the main topics covered in the class, e.g. "buffer overflows". Please use an unordered bulleted list (using *'s in wiki markup). In this section also list readings relevant to the lecture that were mentioned in class.
* Put your notes in the Notes section.

Use (nested) lists if appropriate for the notes; however, please have some text that isn't bulleted. Please try to make the notes even if you did not attend lecture; however, you don't need to cover every small bit of information that was covered. In particular the notes do not need to include digressions into topics only tangentially related to the course. Complete sentences are welcome but not required.

==Security Reading Analysis Guidelines==

A security reading analysis is a detailed analysis of a security research paper. In it you analyze the key arguments of the paper and give your informed opinion.

Most security papers can be classified as attack or defense papers. You should analyze them differently.

For attack papers:
* What systems are vulnerable to the attack?
* What is the nature of the vulnerability?
* What is the the exploit? In particular, what is its technical core?
* How reproducible is the exploit?
* Are there likely to be many similar exploits, in the targeted system or other systems?
* How difficult will it be mitigate/fix the vulnerability in targeted systems?

For defense papers:
* What is the security problem the paper addresses? In what kind of threat model(s) does the problem exist?
* How significant is the problem? Specifically, to what degree do existing solutions not work sufficiently well?
* What is the defense? How does it work?
* To what degree will the defense potentially solve the targeted security problem? In particular, how difficult will it be for attackers to adapt to this defense?
* What are the challenges facing deployment of the defense? Are they likely to be overcome?

For both kinds of papers, you should give your reaction by addressing questions like the following:
* Did you like the paper?
* Was it easy to understand, or was it hard to read?
* Did you learn much from the paper?
* How surprised were you by the result?

Your analysis should not cover the above questions separately (this would tend to make for a very wordy analysis); instead, use these questions as a guide in writing a short essay (1-2 pages) on the paper in question.

Each analysis will be graded out of 10 as follows:
* U: 3 for demonstrating understanding of the content (preferably without summarizing)
* T: 3 for technical analysis (does it work)
* C: 3 for contextual analysis (does it matter)
* V: 1 for your viewpoint

SystemsSec 2016W Lecture 23

2016-04-05T22:08:52Z

Nicholas Laws: Created page with "placeholder"

placeholder