Linked by Thom Holwerda on Thu 3rd Nov 2011 22:54 UTC
Mac OS X And so the iOS-ification of Mac OS X continues. Apple has just announced that all applications submitted to the Mac App Store have to use sandboxing by March 2012. While this has obvious security advantages, the concerns are numerous - especially since Apple's current sandboxing implementation and associated rules makes a whole lot of applications impossible.
Thread beginning with comment 496139
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by frderi
by Neolander on Sun 6th Nov 2011 12:01 UTC in reply to "RE[2]: Comment by frderi"
Neolander
Member since:
2010-03-08

"It is my understanding that in such a case, you actually need at least two vulnerabilities. One to make the web browser execute arbitrary code, and one to make this code break through the OS-level isolation of the web browser. The second vulnerability lies not in the web browser itself, but in system software which it relies on, system software that does itself run as root. But I am not a computer security expert either, so I guess we're stuck there."

The net result is the same, a compromised device.

But the probability is much, much weaker. And if instead of crafting gigantic system components running as root you design the OS as a set of small components with limited responsibility and security permissions, the amount of chained exploits that one must use in order to, say, use a web browser to install a rootkit, becomes quite large.

I don't know it it would be enough to reduce the likeliness of being hacked to a "good enough" level, but I think it's worth trying. Even more since such modularization would also benefit code cleanness, stability, and maintainability.

I don't think the App Store has the capacity to nuke the planet. ;)

Isn't there an app for that yet ? ;)

I don't see Aunt Emma installing Osmos on her Linux box in the forseeable future though. ;)

This is debatable, but I don't want to go into this right now ;) I just needed an OS which I use regularly, and where there are standard packages for software installation. OSX also qualifies with its DMG packages, but that's not the best example of an easy-to-use installation package around (Mounting an image disk and dragging and dropping stuff around ? Why can't I just double-click that downloaded file to get stuff installed ?)

Let's examine each individual step and find out what can go wrong with our friend Joe Sixpack when he wants to purchase an app online :
-Finding the developer's website : He ends up on a phishing site, which looks vaguely similar to the original one. Because he isn't that bright as we are he doesn't notice the difference.

I disagree with this one to some extent. If you know what you're looking for, ending up on a phishing site is quite hard. If I take Google, Yahoo, or Bing and type "Osmos (game)", "Trine", or "SpaceChem", the first link will be the developer's website.

I give you that search engines do get hacked from time to time, though. It would be great if we didn't rely on them so much. But the internet has just grown that big...

-Using paypal : The site states only supports credit card, which requires him to enter his card details, which obviously gets stolen

I can tell ;) I have got a credit card for exactly 3 months before it was stolen, without doing anything obviously stupid with it. Credit cards on the internet is a mean of payment that is broken and insecure at a fundamental level, it shouldn't be used anymore. I wish kids would get told that, perhaps it would motivate bankers to come up with a mean of payment that actually works in the Internet age...

-Downloading a file and clicking an "install" button : The installation installs a trojan, which infects his system with a keylogger after which it phones home to a remote C&C center to take on jobs in relaying email messages for spam and scam attempts.

This actually cannot exist on a well-implemented sandboxed OS. If Joe Sixpack downloads a keylogger installer, he will have at some point to confirm that he gives this piece of software the right to sniff other software's input. Unlike with UAC/Android bullshit where privilege elevation warnings are an everyday annoyance, this is the first time that Joe sees this message when installing a game, so chances are high that he will feel that this is suspicious and cancel the installation.

I know I'm being overly sarcastic here, but you wouldn't believe the amount of questions I get on a regular basis from my customers if its "safe" to buy from a certain website. And even on trusted sites like Ebay, there are still scams going on. As a techie, I know where to look, like checking the WHOIS database of a site, examining security certificates and googling for info about said site, but a lot of users don't know how to do this. At least now I can say "buy from the App Store and you'll be okay".

And I think that this is lipstick on a pig. By doing this, you basically say to your users "you don't know what is good and you can't learn, so let Apple do that stuff for you". But at some point, everyone who spends time on the Internet needs to learn how to discriminate the legit from the scam, be it to a basic extent. Buying train tickets, books, doing online banking... Should all that also be done through the App store ?

Really? I never came across a software on the App Store which didn't work as advertized. Granted, I haven't tried all of them, I'm not that rich. ;)

I have, on iOS. Maybe there is a strong distinction between the iOS and Mac implementations of the App Store concept and I should take more care in specifying which one I'm talking about...

"Conversely, legit demos of commercial software, which allow users to try before buy, are not welcome on the App Store."

Sure they are. Gameloft, for example, publishes both free demos and paid versions of their games.

Then either this set of rules is wrong/not respected, or there is a strong difference between the iOS and Mac app stores and we should both specify what we're talking about : http://en.wikipedia.org/wiki/Mac_app_store

I'm not saying there isn't headroom for improvement in Apple's reviewal process. The people who do it are mortals like you and me. However, especially for smartphones, I think its a good move to make, because of the added dangers of smartphones when compared to PCs.

Are you talking about the extra amount of personal information that phones usually store ? But then, software really should not have access to that information under normal circumstances, and good sandboxing would do the trick.

I don't share your view. Microsoft tried this approach (Windows Everywhere) to the smartphone and tablet market. It never became a success.

Windows was not designed to run on anything but a desktop to begin with. As soon as you specify control position and size in pixels by hand, assume the existence of a "hover" functionality, or fill toolbars without taking care of what happens when window sizes are reduced, your software is already dead as far as cross-device portability is concerned.

And then there is also a serious bloat problem with desktop Windows, which is why phone-oriented releases tend to be based on the inferior and incompatible Windows CE version.

It took a new way of doing things (iOS) which reinvented the basic concepts on how to deal with apps on a UI level for such a product to become usable.

Reinvented on a UI level, really ? Icons, pointers, menus, toolbars, tabs... Current mobile OSs, iOS included, looks more like a set of tweak to the desktop UI paradigms than a reinvention of GUI design to me.

Other devices require other ways of doing things in order to be truly useful for the masses. If they don't succeed in this, they primarily end up being geek toys.

Because it hasn't been tried doesn't mean that it is impossible. If you consider interactions with software at a more abstract level than we currently do, there is no theoretical reason why cross-device portability could not be significantly improved...

But then, I suppose that I should shut up and go back to coding my OS, which aims at experimentally proving this point once I reach the "GUI" part, given that computers still allow running alternative OSs at that time ;)

The publishing cirquit in itself is also already a reviewing process.

Fair enough.

Reply Parent Score: 1

RE[4]: Comment by frderi
by frderi on Sun 6th Nov 2011 14:33 in reply to "RE[3]: Comment by frderi"
frderi Member since:
2011-06-17


But the probability is much, much weaker. And if instead of crafting gigantic system components running as root you design the OS as a set of small components with limited responsibility and security permissions, the amount of chained exploits that one must use in order to, say, use a web browser to install a rootkit, becomes quite large.


If you're already blown off your socks and find this improbable, you should really have a look at how the stuxnet worm works. THAT is scary stuff. If you haven't, it basically targetted specific Siemens controllers of nuclear purification machinery in a certain country. The worm needed to bridge a great distance over the internet, overcome the fact that these machines were not connected to a LAN (so it spread over USB as well), and needed to insert itself into the controller to cause havoc. And it all needed to do it on autopilot, remain undetected and not cause too much collateral damage in the process. Talk about digital warfare. If you read about how it achieved this, the kinds of exploits I mentioned earlier are kindergarten material.


Isn't there an app for that yet ? ;)


There was iNuke by ThePlanet, Inc. on the App Store for a short period, but Apple pulled the kill switch on it. Only minor countries got nuked. ;)

OSX also qualifies with its DMG packages, but that's not the best example of an easy-to-use installation package around (Mounting an image disk and dragging and dropping stuff around ? Why can't I just double-click that downloaded file to get stuff installed ?)


Downloading in Safari will automount the dmg and take out the application for you. For installing system components, you can create .pkg and .mpkg packages. And ofcourse, the App Store already puts the app in the right place for you. Come to think of it, I think not having installers on Mac is better, since contrary to windows, Mac apps don't need all the .dll stuff in the right places to run properly; It also makes clear to the user that running an app won't leave any potential nasty stuff spread around your system.

And I think that this is lipstick on a pig. By doing this, you basically say to your users "you don't know what is good and you can't learn, so let Apple do that stuff for you". But at some point, everyone who spends time on the Internet needs to learn how to discriminate the legit from the scam, be it to a basic extent. Buying train tickets, books, doing online banking... Should all that also be done through the App store ?


I wouldn't mind seeing dedicated software put out by these services to make the process more streamlined. Some of the more important services, like banking transactions for companies, use this approach.



Then either this set of rules is wrong/not respected, or there is a strong difference between the iOS and Mac app stores and we should both specify what we're talking about


I was referring to the iOS App Store. I don't know the reasoning behind disallowing demos of the Mac App Store, but I don't think its a good idea to disallow them.


Are you talking about the extra amount of personal information that phones usually store ? But then, software really should not have access to that information under normal circumstances, and good sandboxing would do the trick.


The access to personal information is just a minor one. Then again, not an unimportant one. Bigger dangers I think are the fact that smartphones have location-based functionality. This can be exploited for all sorts of nasty things. Another thing is that smartphones are basically tiny computers which are mostly always always-on always-connected devices. There will also a great many more of them than desktop PCs. The fact that they're mobile also makes them harder to crack down. Can you imagine a botnet on millions of smartphones? Last but not least smartphones are able to generate additional cost. And whenever there's cost, there's a potential for malicious profit. Thats why I think you need tighter control on smartphone OSes than you need on Desktop PC's. So I think its really crucial that you run up-to-date software on a modern smartphone and have the mechanisms in place to facilitate that. Since the risk for disaster is many times bigger than desktop computers.


Windows was not designed to run on anything but a desktop to begin with. As soon as you specify control position and size in pixels by hand, assume the existence of a "hover" functionality, or fill toolbars without taking care of what happens when window sizes are reduced, your software is already dead as far as cross-device portability is concerned.


Spot on. thats why other devices need other approaches when it comes to UI. But it doesn't stop at just the primary controls. Building a good tablet or smartphone UI is completely different than building a good Desktop app. You can't just "slap on" fixes for these basic controls and call it a day. You need to reimagine the app entirely.


And then there is also a serious bloat problem with desktop Windows, which is why phone-oriented releases tend to be based on the inferior and incompatible Windows CE version.


The primary reason for this is that Windows isn't modular enough and it being a jack of all trades. When you try too do too much, you tend to suck at everything.


Reinvented on a UI level, really ? Icons, pointers, menus, toolbars, tabs... Current mobile OSs, iOS included, looks more like a set of tweak to the desktop UI paradigms than a reinvention of GUI design to me.


Sure, reinvented. The basic building blocks are the same. But they took it down to the building block level and rearranged them in a way which would work well on mobile devices. A lot of the UI conventions and methodology that make sense on a desktop computer don't make sense at all on a mobile app. Mobile apps don't have windows, they work fullscreen. They use other input methods, like you said, they don't use a mouse, so everything tailored towards having a mouse becomes obsolete. This doesn't just include the obvious things like mouseover. It trickles down trough the entire concept of the UI, since the graphical UI's from personal computers were built towards serving the mouse as a pointing device. If you break down your house and rebuild it from the ground up with the same bricks, thats rebuilding to me. Its not "tweaking your current house" by a wide margin. A good tablet app makes a bad desktop app, and a good desktop app makes a bad tablet app, so its crucial to reimagine it.


Because it hasn't been tried doesn't mean that it is impossible. If you consider interactions with software at a more abstract level than we currently do, there is no theoretical reason why cross-device portability could not be significantly improved...


Interesting idea, I'd like to see that in action sometime.

Reply Parent Score: 1

RE[5]: Comment by frderi
by Neolander on Sun 6th Nov 2011 16:35 in reply to "RE[4]: Comment by frderi"
Neolander Member since:
2010-03-08

If you're already blown off your socks and find this improbable, you should really have a look at how the stuxnet worm works. THAT is scary stuff. If you haven't, it basically targetted specific Siemens controllers of nuclear purification machinery in a certain country. The worm needed to bridge a great distance over the internet, overcome the fact that these machines were not connected to a LAN (so it spread over USB as well), and needed to insert itself into the controller to cause havoc. And it all needed to do it on autopilot, remain undetected and not cause too much collateral damage in the process. Talk about digital warfare. If you read about how it achieved this, the kinds of exploits I mentioned earlier are kindergarten material.

I agree that software protections which are good enough against everyday desktop and mobile threats will be insufficient against targeted attacks with colossal financial and human means like Stuxnet. When you're facing this sort of attacks, you need NASA-like permanent code auditing and warfare-like financial and human means to achieve good security.

However, I also believe that that the average desktop/mobile user is not likely to have to worry about this anytime soon.

Downloading in Safari will automount the dmg and take out the application for you. For installing system components, you can create .pkg and .mpkg packages. And ofcourse, the App Store already puts the app in the right place for you. Come to think of it, I think not having installers on Mac is better, since contrary to windows, Mac apps don't need all the .dll stuff in the right places to run properly; It also makes clear to the user that running an app won't leave any potential nasty stuff spread around your system.

Hmmm... Which version of OS X are we talking about here ? I think that on the (admittedly a little old) 10.5 machines which I'm used to, Safari automatically mounts and opens dmgs but does not do anything else.

I really, really do not like Windows-like installers, but I see the value in standard packages whose installation goes a bit beyond copying a folder at a standard location. File associations, applications which start on system boot, security permissions... All that benefits from being managed at once during "installation" time.

I wouldn't mind seeing dedicated software put out by these services to make the process more streamlined. Some of the more important services, like banking transactions for companies, use this approach.

I see a value in having sensitive stuff such as banking managed by web services myself. When a vulnerability is discovered in a piece of code which handles financial transactions, you really want that vulnerability to be fixed immediately, and nothing beats web-based services for ease of updating ;)

But I guess that the risk is small for extremely simple applications which are just an I/O peripheral for a big cloud service.

The access to personal information is just a minor one. Then again, not an unimportant one. Bigger dangers I think are the fact that smartphones have location-based functionality. This can be exploited for all sorts of nasty things. Another thing is that smartphones are basically tiny computers which are mostly always always-on always-connected devices. There will also a great many more of them than desktop PCs. The fact that they're mobile also makes them harder to crack down. Can you imagine a botnet on millions of smartphones? Last but not least smartphones are able to generate additional cost. And whenever there's cost, there's a potential for malicious profit. Thats why I think you need tighter control on smartphone OSes than you need on Desktop PC's. So I think its really crucial that you run up-to-date software on a modern smartphone and have the mechanisms in place to facilitate that. Since the risk for disaster is many times bigger than desktop computers.

Alright, I give you this one ;) In this light, smartphones are indeed a quite "dangerous" piece of tech that must be handled with care.

Spot on. thats why other devices need other approaches when it comes to UI. But it doesn't stop at just the primary controls. Building a good tablet or smartphone UI is completely different than building a good Desktop app. You can't just "slap on" fixes for these basic controls and call it a day. You need to reimagine the app entirely.

You are right that cross-device portability, if possible, would be about much more than basic UI fixes. I've not started full work on that yet, but an interesting path to study, in my opinion, would be to start with a relatively abstract theory of human-computer interactions, then gradually specialize it towards the kind of devices and users which the OS or application wants to target.

Like, if we went extremely far on the "abstract" end of the spectrum, a basic clock application's UI would transmit a periodically updated text information to the user. And an SMS inbox would ask the user to pick an object from a list of items that are defined by a set of characteristics (Sender, short description, reception date, read/not read), where items which are not read are highlighted by the UI.

This is to be contrasted with the current approach to UI design, which at the other extreme aims at describing every single detail of the user-software interaction, and as such is extremely vulnerable to a change of hardware, be it only a move to a different screen size.

Of course, there are less extreme approaches in the middle, with both some control and some flexibility. And then there is the multiscalar approach, where developers start by designing their UI at a very general level, then define the specifics of some forms of interaction which they specifically focus on (keyboard, finger, mouse and voice input, screen and voice output...)

The primary reason for this is that Windows isn't modular enough and it being a jack of all trades. When you try too do too much, you tend to suck at everything.

And when you do too little, people just say "meh" and move along ;) I guess that defining reasonable goals for a product must be one of the hardest tasks of engineering !

A lot of the UI conventions and methodology that make sense on a desktop computer don't make sense at all on a mobile app. Mobile apps don't have windows, they work fullscreen. (...)

Well, they do have windows, in the sense of a private display which the application may put its UI into without other software interfering. It just happens that these windows are not resizable, full screen, and as a consequence are hard to close and can only be switched using the operating system's task switcher. Which makes multi-windows interfaces impractical. But those ought to disappear anyway ;)

And although they do not have a mouse, they still have pointer-based UIs. Only this time, the pointer is a huge greasy finger instead of being a pixel-precise mouse, so hovering actions must not be a vital part of the UI, and controls must be made bigger to be usable. Since controls are bigger and screens are smaller, less controls can be displayed at once, and some controls must either go of be only accessible through scrolling. But this does not have to be fully done by hand, UI toolkits could do a part of the job if the widget set was designed with cross-device portability in mind...

Edited 2011-11-06 16:38 UTC

Reply Parent Score: 2