SystemsSec 2016W Lecture 23

From Soma-notes

Topics and Readings

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