4 ms·
Ah, yes, This is where safety and security differs! Abstraction is about safety: preventing errors and giving additional guarantees, not preventing attacks. :)
by Drup 9y ago
Ah, yes, This is where safety and security differs! Abstraction is about safety: preventing errors and giving additional guarantees, not preventing attacks. :)
Nothing I said hold when people are being malicious: Even in OCaml, you have escape hooks that allows you to break past abstraction boundaries and do whatever you want.
- skybrian 9y agoAgreed, but this is where our own jargon betrays us: in ordinary usage by non-programmers, "safety" includes safety from attacks. Perhaps especially from attacks?
- Tomte 9y agoOrdinary usage is often murky, but the usual distinction between security and safety is not whether it is about an attack, but about the direction of the threat. Safety means the environment is not harmed by the system. Security means the system is not harmed by the environment.
- nickpsecurity 9y agoThat's an interesting definition. Traditionally, we had several ways of looking at it: 1. Safety contends with accidents like components breaking. Security contends with malice where input is crafted and failures are set up intelligently to do damage unlikely to happen on accident. There's quite a bit of overlap, though. 2. If talking leaks, safety rarely requires confidentiality of data. It's usually integrity or availability that it shares with security. So, a security violation with covert/side channels might not be a safety violation. Just two off top of my head to illustrate the difference.
- lmm 9y agoI think of it the same way you'd think of it in a workshop: a "safe" drill or saw is one that can be used in a safe way, not one that's safe from deliberate attacks.
- nickpsecurity 9y agoThere's work to address that. Look into proof-carrying code and "fully-abstract compilation." There's also been proofs done for hardware and assembly against specs in ACL2 and Abstract, State Machines.