Real Security in Mac OS X Requires Apple-Signed Certificates(blog.wilshipley.com) |
Real Security in Mac OS X Requires Apple-Signed Certificates(blog.wilshipley.com) |
He's right that sandboxes won't directly prevent malware. But that's not why users want sandboxes. Sandboxes mitigate accidental vulnerabilities. Virtually every security vulnerability you've ever heard about has been an accident.
Sandboxes aren't a new idea (the sandbox code didn't even originate at Apple). The idea goes back to the '70s; an obvious and more recent example is the Java applet sandbox, and a somewhat more successful instance is Daniel Bernstein's qmail security architecture (qmail has one of th best security track records of any major software package).
It's best to think of sandboxes not as a preventer of malice, but as one incremental form of forced developer competence: all developers are being asked to at least consider what privileges their applications need (most developers do not do this today), so that they can voluntarily renounce capabilities that will be turned against them when someone finds a heap overflow in their code later on. The technology and policy Apple is working with here will do a fine job of that.
Also, no matter what Bertrand Serlet said, sandboxes don't need to cover "as many instructions as are in the human brain". Because of its Mach / Unix underpinnings, sandboxes have a relatively simple user/kernel interface they actually need to deal with. There are just a few hundred system calls, many of them already privileged.
This is also similar to dropping privileges in unix: if you need sudo to start up, you drop it as soon as possible so that a compromised binary doesn't lead to root access for the malware.
They are like fire doors. They don't prevent the fire, they just limit the damage. Anything that encourages developers to adopt the sandbox model is good, however I would say that requiring them everywhere is probably biting off more than they can chew. Furthermore - as Wil explained - being fast with the fire extinguisher is probably a better tactic than trying to monitor and disallow all things that may lead to fire.
I disagree here. In the case of humans, it doesn't cost much to put fire extinguishers at regular intervals and have people just use them in the case of a fire. If a first starts we'll notice it. On a computer, it won't "just notice". You would have to have some virus scanner scanning every action all the time. This is what makes Windows so much slower and I would really hate to see it come to Mac.
I wish the SELinux approach would become more popular.
The point about all security models is that you need multiple redundant systems not one silver bullet. My house is built to fire safety codes, the materials are tested and approved individually, we have fire alarms, fire extinguishers, a fire hydrant nearby and a fire department to use it, and we have fire insurance. Most houses are like this and houses still burn down.
Shipley's argument is that code signing is all you need. It's not quite the same as advocating fire extinguishers as the only line of defense against house fire, more like simply relying on your builder's credentials.
But to be fair - I think the hardware is only now starting to get fast and capable enough for doing security via virtualization. So up until now may be OS vendors did not really have the luxury of thinking along those lines but it doesn't hurt to start thinking now.
Apple could really leapfrog if they worked with the hardware vendors to make Mac OS X something like QubesOS but much more usable. On top of it if they had a saner programming language that makes it darn near impossible to make security goof ups, real security still has a chance!
Similar logic would allow the "we - implemented - the - kernel - in - a - type - safe - runtime - so - we - don't - even - need - to - switch - out - of - ring - zero" crowd to say Qubes was inadequate.
[EDIT] Relevant Article (via /.) - http://www.networkworld.com/news/2011/110311-xen-simon-crosb...
The OS X sandbox has been around for a long while (and trusted BSD has been around for even longer), it is of course not bug free, but it is in use in a few exposed applications (like Safari), and deploying it appstore-wide will only make it even better.
I, as a programmer, sleeps better at night knowing that my (and others) applications has safety nets that protect it from doing stupid stuff.
Actually I don't think this will work. They can "shut it down" in the sense that they can keep new installs from happening. But if the malware is already installed it controls the machine, so it can simply ignore the "kill switch" for itself.
The way it (supposedly) works is that you have a hardware chip that checks the bios, which checks the boot loader, which checks the os, which checks the apps etc.. The goal is that you'll have to modify the actual hardware chip in order to "crack" the os. Sounds great, but has a lot of challenges in practice.
"Bertrand Serlet once told me that Mac OS X now has roughly as many instructions as we believe the human brain does."
If one had to express the complexity of a neuron in the size of its 'instruction set', the best guess may be 'one': "act like a neuron until you break down".
The complexity of the brain most likely is not caused by complexity of the processing units, but of its parallelism.
(One of these things is not like the others: http://www.google.co.uk/search?q=Bertrand+Serlet&pws=0)
I too want to develop a Mac app that might not be covered by the existing entitlements and would be disappointed if I couldn't release it via the MAS.
Hopefully Apple will read this and consider his insights.
Signing certs for Mac software would be different because there is exactly one central signing authority (Apple), so batch-downloading a list of revoked certs is feasible - bundle them with your monthly security patch updates, for example.
Downloading blacklists of certs is exactly what happens. They are called OCSPs and CRLs. The operating system is responsible for tracking these through a combination of caching and downloading new OCSPs/CRLs. The database does not grow too large, because CAs use certificate chains. The cert that is vouching for some website is not the cert in your trusted root store. Root store certs are kept under lock and key - these very rarely get compromised (this is what happened to DigiNotar and they are no longer in business - their certs were invalidated by everyone in the industry and they were filing bankruptcy less than a month later).
What does happen are leaf certs being compromised. When this occurs only that leaf and everything below it in the chain is revoked, so if you have enough certs in the chain you usually don't revoke many certs at a time. Generally speaking, the lower the cert in the chain the lower the trust level, which includes stuff like the cert not remaining valid for as long a period.
You can read about how Windows implements cert revocation here: http://technet.microsoft.com/en-us/library/ee619754%28WS.10%...
I'd assume Apple does something very similar.
If someone is alreay man-in-the-middling you with a cert you trust, they can easily filter the revocation lists that you download.
OCSP is a privacy problem, as well as a bottleneck/performance problem for any large, non-organizational CA, such as Verisign and their compatriots. Every single SSL certificate must be checked at each handshake in order to make sure it hasn't be revoked in the past 'n' hours (there is some caching, which kind of defeats the purpose). This means that in practice, the CA's know who is visiting what sites, and that they must be online and active and responding in a timely fashion (like the DNS) before a browser will allow an HTTPS connection.
So the man-in-the-middle attack can keep the client ignorant of the contents of the CRL, but can't trick the client into believing a revoked certificate has not been revoked.
SSL is a red herring here, since we care about authenticity, not privacy.