Linked by Thom Holwerda on Tue 1st Mar 2011 00:28 UTC
Mac OS X It's sad to see that even after all these years, we still have to write articles like this one. It's all over the web right now: a new backdoor Mac OS X trojan discovered! Code execution! Indicative of rise in Mac malware! Until, of course, you actually take a look at what's going on, and see that not only is it not in the wild, it can't really do anything because it's a beta.
Thread beginning with comment 464539
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Maybe I'm crazy...
by kaiwai on Wed 2nd Mar 2011 12:53 UTC in reply to "RE[4]: Maybe I'm crazy..."
Member since:

OSX provides the feature, sure, but is it really pushed forward ?

Do the Apple guys put agressive sandboxing in Xcode's basic application, as a default Xcode setting ? Do they mention sandboxing in their tutorials and doc ? Sure, if it's just some random feature lying around along with the thousand of others, things are certainly not likely to change... Until the day where security issues will become critical, that is, and that day Apple will have no choice but to *brutally* sandbox everything, the UAC way (and we both know how effective this is, as you mention it in your comment).

Yes, Microsoft has pushed it as soon as it appeared in Windows and same with Apple when it first appeared in Mac OS X. Developers don't add it because they're lazy but I do think there is one way they can get people to do it - by making it a requirement for applications submitted to the AppStore. If they make it a requirement for the AppStore then you might find vendors.

Btw, UAC doesn't sandbox a thing - UAC is temporary privilege escalation and nothing to do with sandboxing. All UAC tells you is that an application is requesting privilege escalation but but it doesn't actually sandbox the application in anyway when running as a normal user. Windows has sandboxing and Adobe is finally using it for Acrobat X (but not comprehensively) in much the same way that Google has taken advantage of sandboxing in Windows and Mac OS X.

Edited 2011-03-02 12:55 UTC

Reply Parent Score: 2

RE[6]: Maybe I'm crazy...
by Neolander on Wed 2nd Mar 2011 15:41 in reply to "RE[5]: Maybe I'm crazy..."
Neolander Member since:

Not sure I worded my post properly, because it seems you didn't understand what I was trying to say. Here's another try...

With Windows NT, Microsoft have introduced some true multi-user mechanism, and the root/user security model based on that. Normally, Windows applications should now use HKEY_CURRENT_USER and the Users/Document&Settings folders to store their data, and nothing else. Sadly, some developers kept their old coding practices from the Win9x era, since "it worked".

As a result, Microsoft have forced them to change, by making sure that all applications requiring root access display an annoying UAC popup on startup. Net result : terrible user experience, and users end up ignoring the popups because they are encountered too frequently. But Microsoft didn't really have a choice.

Apple, to the contrary, do have a way to update their security model more cleanly, because they control Xcode, an IDE which AFAIK nearly everyone developing for Apple OSs use.

So they can modify Xcode's default settings so that by default, it sets up highly aggressive sandboxing for all applications. This way, developers won't be able to code the old way (writing config files randomly in the user's home folder, etc...). Developers trying to use old development practices will see that they fail, try to understand why, and discover that it's because of sandboxing. At this point, I bet many will think "hey, great idea, didn't know about that !" and try to learn more. Of course, there will still be others who alter Xcode's settings so that it works the old way, or keep the old release of Xcode. For those, making sandboxing mandatory on the App Store would indeed be a good option.

Edited 2011-03-02 15:44 UTC

Reply Parent Score: 1