Real Security in Mac OS X Requires Apple-Signed Certificates • Hacker News Board

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

#21

Post by tptacek » Fri, Nov 04, 2011, 1:03 PM UTC

blinkingled wrote: post #4

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

It's probably not reasonably to compare a hugely popular general purpose operating system to a research prototype designed specifically to demonstrate an extreme form of application segregation.

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.

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

#22

Post by Tloewald » Fri, Nov 04, 2011, 2:45 PM UTC

danssig wrote: post #15

po wrote: 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…

Being fast with a fire extinguisher is no substitute for fire prevention :-)

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.

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

#23

Post by blinkingled » Fri, Nov 04, 2011, 2:54 PM UTC

tptacek wrote: post #21

blinkingled wrote: post #4

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

It's probably not reasonably to compare a hugely popular general purpose operating system to a research prototype designed specifically to demonstrate an extreme form of application segregation. 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.

QubesOS is Linux+Xen+Added Trickery on top. So calling that a research prototype may not be entirely correct. I have used QubesOS - besides hardware support and usability there are no real inadequacies as far as I could tell from a general purpose desktop OS standpoint - both of which can be fixed by Apple along with may be some more hardware integration.

[EDIT] Relevant Article (via /.) - http://www.networkworld.com/news/2011/110311-xen-simon-crosb...

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

#24

Post by Someone » Fri, Nov 04, 2011, 5:24 PM UTC

delinka wrote: post #16

dfc wrote: 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.

I think the claim is bogus not because the brain has a much more complex instruction set, but because the phrase 'instruction set of the brain' does not make sense.

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.

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

#25

Post by pyre » Fri, Nov 04, 2011, 7:02 PM UTC

chalst wrote: post #9

pyre wrote: post #7

Earlier quoted context omitted.

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

I was mostly commenting on the first paragraph in relation to the web, not specifically about Apple using certificates.

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

#26

Post by pyre » Sat, Nov 05, 2011, 12:59 AM UTC

chalst wrote: post #9

pyre wrote: post #7

Earlier quoted context omitted.

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

Also...

  > provided Apple's own CA hasn't been compromised

We've been seeing this happen a lot lately, so that's a big assumption.

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

#27

Post by po » Sat, Nov 05, 2011, 2:04 AM UTC

danssig wrote: post #15

po wrote: 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…

A bit of confusion: when I said 'fast with the fire extinguisher', I wasn't talking about users but about Apple. Malware is only practical if you can infect hundreds if not thousands of machines. If Apple can effectively kill malware that is discovered, then it ruins the economics behind it. So to apply my somewhat lacking analogy, even though the systems are horribly vulnerable and there is nothing a user can or should do if a fire starts, nobody is out there going around starting fires because they get put out by Apple quickly, with some cost to them and before the fire is useful.