Hacker News new | past | comments | ask | show | jobs | submit login

Apart from that it doesn't get you any additional protection whatsoever. With all the root OS X exploits floating around that bust you out of the sandbox as well as giving you full system access, as someone that has several utilities on the Mac App Store, it would be trivial to put an app there that gets set off by a timer, exploits root, and wreaks havoc.

Source: https://www.google.com/search?q=os+x+root+exploit&gws_rd=ssl




This is a totally unproductive (if all too common) attitude toward security. "If it doesn't solve every problem, it's useless."

This protects against a whole host of issues. It safeguards against garden-variety incompetence[1]. It provides some defense against the large number of badly-intentioned people who can write an Objective-C app, but don't have the expertise necessary to weaponize a typical root escalation exploit. It prevents apps from accessing your contacts, reading your emails, determining your location, and accessing the webcam and mic without your knowledge, amongst other things.

Does it protect against a motivated, highly technical attacker? No, not really. But that hardly makes it useless.

[1]: http://www.macobserver.com/news/98/december/981229/bungierec...


Not to mention that exploit will be fixed soon.


>It safeguards against garden-variety incompetence[1]. It provides some defense against the large number of badly-intentioned people who can write an Objective-C app

The exploits tend to be trivial, often trivial enough to fit into a single tweet. (https://twitter.com/i0n1c/status/623727538234368000) They require no competence to use.

As for protecting against incompetence and mistakes, that is far too an extreme of a measure solely to protect against that. Some decent QA will fix that.

So what is the point, really, of sandboxing if it does not thwart highly technical attackers? It severely limits the functioning of apps, makes it far more difficult for app developers (myself included), and for what benefit that could be worth the trade off?

https://www.google.com/search?q=developers+leaving+%22mac+ap...


> So what is the point, really, of sandboxing if it does not thwart highly technical attackers?

It thwarts the attackers who aren't highly technical, and frustrating the script kiddies could have flow on effects when beginner attackers don't get the reinforcement to motivate themselves to refine and build their skills.

Secondly, exploits can be patched over time. Ten years from now, is OS X going to be better off for having the sandbox? Do you expect a lot of trivial exploits to be discovered after another century of person-hours are invested in the sandbox?


I mean I can easily install an app to try it out, then uninstall and be reasonably sure it’s completely gone, without changing the rest of the system by incompetence or ignorance. That’s still pretty good. If the developer wants to harm you intentionally, that’s tough game on any system.


Your logic holds true for things like filesystem permissions and even separate user accounts. Since a privilege escalation exploit could give you root access, might as well do away with limited users and run everything as root to begin with, right?

And yet we do those things anyway. The idea is defense in depth, such that if one mechanism fails then hopefully another will mitigate the damage. Sandboxing isn't perfect, but it's another layer of security and I'd rather have it than not.



Which is completely pointless. If a hacker wants to hack your system, the very last thing they want to do is destroy your OS. Who cares about the OS, it's just one re-install away and you got it back. If a hacker were to hack into your system they would want your data, your passwords, your bank account details etc. Or they would want to use your system to do illegal things that look like you did it.

It's in the best interest of the hacker that broke into your system that your system continues to work flawlessly for both you and the hacker. This is why Mac OS X "rootless" is just yet another obstacle for the power user, yet another obstacle when compiling and installing POSIX code from source, and yet another step closer to locking down OS X to be an appliance like iOS.


The point of rootless (SIP) is to prevent malware from being able to embed itself into the system such that it's difficult or impossible to remove. And it's also a completely different technology than sandboxing.


Which in of itself is pretty much an impossible goal, and in the meantime, it destroys a litany of use-cases that make computers useful to people.


No it doesn't. It should be vanishingly rare for software not shipped by Apple to be impacted by rootless. The whole point of the feature is to prevent files that should never be modified from being modified. The only software that I can think of that's impacted by rootless is Xcode, which is of course Apple's own app. I can't think of anything else that should be hampered by the inability to modify system files. Can you name any other software that has a problem with this?

And if you really want to disable rootless anyway, you can do so. Boot into the recovery partition and there's an option there to turn off rootless.

I'm also completely baffled by the claim that, just because no security solution is 100% perfect, that we shouldn't even try. That makes no sense at all. Yes, security is hard. But protecting you from 99% of all malware, even if there's the rare case of malware that gets past you, is still extremely useful. Besides, it's awfully cynical to declare that SIP is an impossible goal before you've even looked at it.


Just found one yesterday: https://github.com/binaryage/asepsis/issues/30

But, you can disable SIP so not sure how much it really matters.


Oh geeze. That doesn't even have anything to do with rootless. The issue there is library interposing. Asepsis works by interposing itself into every process that links DesktopServicesPriv.framework and replaces several libc calls.

Good catch on finding something that breaks with SIP, but even if you philosophically disagree with the idea of rootless, you should still agree with the notion that library interposing is a serious security threat and should welcome the changes to block interposing of system processes[1].

[1] From the What's New In El Capitan docs[2], the specific aspect of SIP that applies here is "Code injection and runtime attachments to system binaries are no longer permitted".

[2] https://developer.apple.com/library/prerelease/mac/releaseno...


I don't really know enough to form an opinion one way or the other, I just had recalled seeing it at the time I read your post. I wouldn't have used Asepsis even if I wasn't on El Capitan as I definitely didn't like the sound of how it achieved what it claimed (which you also pointed out).


The only way I can get features that are important to my daily work is to interpose system processes.

So no, I don't welcome "SIP". There are better ways to solve that problem.


There really aren't better ways to solve that on a mass scale at this time. I intend no offense but to be honest I care much more about my system's security vs your need to interpose system processes. SIP is a step in the correct direction for security. Is it perfect or a catch all? No of course not but it's another layer of security that helps the situation overall.


And this is why we can't have nice things.

I recommend that you tally up the revolutionary technologies produced over the last 30 years that allowed us to get to this point (including the web), and then consider how many of them could be invented on Mac OS or iOS today.


The point of rootless is that doing privilege escalation attacks will be much more difficult


Except you have get through Apple's code review and then once you activate Apple can push a button and wipe out all the installs with a single button push.

Yeah, cracking is asymmetric warfare that we have no hope of winning, I think anyone with any knowledge of computers realizes that is true. It doesn't mean we should smugly shoot down anything that makes it incrementally harder.


That is nothing that cannot be trivially obviated with a date check before doing bad stuff.


That seems to be orthogonal to the sandbox, which is the measure under criticism here.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: