OSWebSec: App Perms & Hyperviz

From Soma-notes
Revision as of 12:21, 6 November 2012 by Afry (talk | contribs) (Created page with "Operating System and Web Security November 6, 2012 Presentations – 10 – 15 minutes for presenting and 5 – 10 minutes questions. Present the basic ideas of the paper...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Operating System and Web Security November 6, 2012

Presentations – 10 – 15 minutes for presenting and 5 – 10 minutes questions.

Present the basic ideas of the paper – collecting your thoughts and ideas you are working on while developing the paper.

5000 – 10000 words ( 6 – 8 pages ) - ACM dual column.

Classic unix model – you are a developer – you are running a program – unix is a giant ide in some respects. What is the hypothesis?

Look at these permission models – is this the only way to do things? I wouldn't say this paper necessarily answers all or most of them. All its saying is how do these developers assign these permissions. Are they assigning dangerous permissions or are they not ?

It seemed to say that programmers are being conservative with the assignment of permissions.

What percentage of people are law – abiding? Most people don't engage in violent crime. Am I going to walk down the street @ 2 am. Just because most app developers don't overclaim most app permissions, doesn't say anything about those that would. Think about an app store where most of the apps are well behaved. How likely is a user going to see that it's asking for too many permissions? Its' hard to find the permissions until you actually do an install.

Nice things about app permissions. The story the author's want to tell, and then the story the data actually tells.

Look at the results that they have – 17% requested more Conclusion of the paper is that app permissions work. This paper is not about utility of app permissions, but it is about what permissions do apps have. How useful is it to ask users anything related to security? With all security mechanisms it all comes down to enforcement

there's enforcing the permissions at runtime, and making sure you have the right permissions. People haven't thought if you have the right permissions – most apps get the policy right. It's the small minority of cases where the policy is wrong is where you get rude. Developers seem to follow social norms. Partially its interesting to see how people look at app permissions – context of a review process – gives reviewing organization a way to enforce rules. At runtime you know, even if the code changes / has some backdoor this is all the access that the system can possibly have. You are restricted to this. If you think about permissions from perspective of a reviewer – finer grained permissions require more work. Current application permissions are sufficiently usable and developers are generally well behaved enough to make sure that they are within appropriate application models.

Using hypervisors

we've tried to use vms for security – proxos was one answers, patagonix and sensors were another answer.


Proxos – what is it? Virtual machine monitor – what are they trying to do? You are using vms – vms are about walls – building a wall between the application and the os. Wanted to run a process in a virtual machine – all the data was kept on the virtual – to do it they had to run an operating system inside the vm. It's an application specific vm – it routes certain calls to the untrusted OS – other ones it doesn't have to.

How does proxos compare to a classic process? They want more protection – if they use a vm to protect it – code base is smaller – it's kind of a super process – where you get to go directly to the hardware, but still have a regular operating system to do more sophisticated services. Own private store it can't touch, can separate it off. Proxying calls instead ofprocess being on top of the kernel – it's to the side- most of it's services are from the main operating system. What sort of attacks does that protect against? - Rootkit infected operating system. Where does user interaction go through ?

Can provide a trusted little environment – the other thing is – the trusted little environment to store / do something - other thing is a toehold to trust the other system – have something else do the introspection.

There's a fancy technology – and here's what you can do with it. I can separate them – okay now it's separate. I can observe – but I don't know how anything works – semantic gap problem – how does it know what's going on? General problem – when you want to have a trusted place to observe the system at a very low level you have to go through and interpret abstractions of those above it – now you have this other thing that's trying to go in and inspect them. Malware – assumptions you make about how the system behaves – more you assume about how the system works – the more likely the target can get around you. There are some tricks. This is taking a security problem and make it a general program understanding problem – we know that it's not computable. The turing machine can't do it – it's the halting problem. It's a general problem – the vm is trying to understand how the regular operating system or applications are running – determining any property of a program is reducable to the halting problem, and this is trying to find non trivial problems.

You run a program – tell me whether this program is going to halt. If I give you this program how can I tell whether this program is actually going to stop. Introspection is trying to solve the halting problem – doesn't mean that you can't do any of it, you are only going to get an approximate solution. For the purposes of security – the vm could try parsing the state and if it can't figure it out it stops. We'll observe some of it – what can we do with it? Executing one program making sure that the binary code was unaltered – doing checksumming of code – not even of the dynamic state. I've got this giant hammer and I smashed a walnut. I ahve these nutcrackers that can do the same thing.