Real Security in Mac OS X Requires Apple-Signed Certificates
blog.wilshipley.com
Real Security in Mac OS X Requires Apple-Signed Certificates
1–10 of 27 posts
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#2Sandboxing in the appstore is probably not intended to directly protect against malware, it is there to minimize the risk of programmer error. The application developer decides the restrictions it imposes on itself. And while the current entitlements system seems quite weak compared to the normal interface to the sandbox, I think that the number of entitlements that you can request will grow with time, and with user awareness. (The Scheme-derivative that is the configuration right now, is probably not fit for user consumption)
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.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#3I have the greatest respect (nay, love) for Mr. Shipley (who can forget his live twitter coverage of the bachelor), but hasn't web certificate revocation proven to be pretty much un-workable in practice? How would this be different? Entitlements sound similar to code access security which Microsoft baked in to the CLR, but which remain largely un-used.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#4I would argue that real security requires a deeper approach like QubesOS takes - http://wiki.qubes-os.org/trac/wiki/SecurityGoals . Constraining and inconveniencing users for the sake of false sense of security doesn't feel like something that needs to be attempted in 2012.
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!
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#5This article by Wil Shipley is grounded in so much real world experience.
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.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#6I have the greatest respect (nay, love) for Mr. Shipley (who can forget his live twitter coverage of the bachelor), but hasn't web certificate revocation proven to be pretty much un-workable in practice? How would this be different? Entitlements sound similar to code access security which Microsoft baked in to the CLR, but which remain largely un-used.
The problem with revoking certificates for websites is: how do you know when to check if a certificate is black-listed? You can't download a list of blacklisted certificates, because who would keep track of them all, and how huge would the database be? Some certificates include the URL of a 'revocation list' which allows the browser to check if that certificate has been revoked, but if the browser checks each certificate that it sees then suddenly Verisign's revocation list server becomes a single-point-of-failure for half the Internet, and that's no good either.
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.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#7I have the greatest respect (nay, love) for Mr. Shipley (who can forget his live twitter coverage of the bachelor), but hasn't web certificate revocation proven to be pretty much un-workable in practice? How would this be different? Entitlements sound similar to code access security which Microsoft baked in to the CLR, but which remain largely un-used.
The problem with revoking certificates for websites is: how do you know when to check if a certificate is black-listed? You can't download a list of blacklisted certificates, because who would keep track of them all, and how huge would the database be? Some certificates include the URL of a 'revocation list' which allows the browser to check if that certificate has been revoked, but if the browser checks each certifi…
The real problem with revocation lists for websites is that there is no secure channel to transfer them over. You can't transfer them over SSL because you don't know which certs you shouldn't trust until you get the list.
If someone is alreay man-in-the-middling you with a cert you trust, they can easily filter the revocation lists that you download.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#8The application sandbox should be considered like not storing credit card info on your system... you could do it but you open yourself to security problems. As a developer, you should opt into entitlements because it means that your application will be less likely to have a problem in the future.
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.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#9Earlier quoted context omitted.
The problem with revoking certificates for websites is: how do you know when to check if a certificate is black-listed? You can't download a list of blacklisted certificates, because who would keep track of them all, and how huge would the database be? Some certificates include the URL of a 'revocation list' which allows the browser to check if that certificate has been revoked, but if the browser checks each certifi…
The real problem with revocation lists for websites is that there is no secure channel to transfer them over. You can't transfer them over SSL because you don't know which certs you shouldn't trust until you get the list. If someone is alreay man-in-the-middling you with a cert you trust, they can easily filter the revocation lists that you download.
But you can know whether a CRL is valid, provided Apple's own CA hasn't been compromised. If Apple were to issue a complete CRL every 6 hours or so, then man-in-the-middle filtering won't work since clients can simply not trust any new signatures until they have seen the current CRL.
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.
Re: Real Security in Mac OS X Requires Apple-Signed Certificates
#10Does anyone know anything more about this:
"Bertrand Serlet once told me that Mac OS X now has roughly as many instructions as we believe the human brain does."