Live data from Hacker News

Real Security in Mac OS X Requires Apple-Signed Certificates

blog.wilshipley.com

11–20 of 27 posts

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#11

I 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…

What? Your first paragraph concludes that if everyone is checking Verisign's CRL they become the single point of failure for half the internet, yet you conclude the a better solution is to only check Apple's certs, making them the ONLY point of failure? I don't think you really understand how digital certificates work.

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.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#12
"Apple then has the power, if any app is found to be malware, to shut it down remotely, immediately"

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.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#13
post #12

"Apple then has the power, if any app is found to be malware, to shut it down remotely, immediately" 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.

Is there not some way that the certificate checks can run on app launch? Or even periodically

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#14
post #13
post #12

"Apple then has the power, if any app is found to be malware, to shut it down remotely, immediately" 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.

Is there not some way that the certificate checks can run on app launch? Or even periodically

I don't know how mac "apps" work, but if we assume it can gain full control over the os, there's really only one thing they can do: "anchor" the checks in hardware.

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.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#15
post #8

The 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…

>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.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#16
post #10

Does 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."

I don't know what a Bertrand Serlet is but the statement reads like bunk. The CommonSense-Ometer in my own brain says there's no comparison between the evolved complexity o the human brain and an operating system for the modern digital computer hardware.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#17
post #16
post #10

Does 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."

I don't know what a Bertrand Serlet is but the statement reads like bunk. The CommonSense-Ometer in my own brain says there's no comparison between the evolved complexity o the human brain and an operating system for the modern digital computer hardware.

Bertrand Serlet was the head of Mac OS X at Apple from 2003 to 2011.

(One of these things is not like the others: http://www.google.co.uk/search?q=Bertrand+Serlet&pws=0)

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#19

Earlier 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…

What? Your first paragraph concludes that if everyone is checking Verisign's CRL they become the single point of failure for half the internet, yet you conclude the a better solution is to only check Apple's certs, making them the ONLY point of failure? I don't think you really understand how digital certificates work. Downloading blacklists of certs is exactly what happens. They are called OCSPs and CRLs. The operat…

Just a nitpick, but OCSPs is not the plural of OCSP, and you don't 'download' it the way a CRL works. OCSP stands for 'Online' Certificate Status Protocol, and is a query/response protocol, that functions much like the DNS - you don't download the whole deal, you ask about the validity of a specific, single record, and get a 'yes'/'no' response.

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.

Re: Real Security in Mac OS X Requires Apple-Signed Certificates

#20
I think Shipley has missed the point of OS X sandboxing.

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.

Post reply on HN