4 ms·

"While it is possible to hide or obfuscate calls to APIs that are not included in the SDK, this is still a violation of customer expectations and Store policy."

"While it is possible to hide or obfuscate calls to APIs that are not included in the SDK, this is still a violation of customer expectations and Store policy." Wait, does the platform not include a sandbox to make sure this doesn't happen? What "security" can you expect to get out of such a platform?

riffraff 14y ago
isn't it the same that happens on iOS ?
- rbanffy 14y ago
  Doesn't look like that: http://www.apple.com/iphone/business/docs/iOS_Security_Mar12.pdf http://www.apple.com/iphone/business/docs/iOS_Security_Mar12...
- dpark 14y ago
  Yes, this is exactly the same (or at least awfully similar). iOS has some APIs that are technically available to 3rd parties, but disallowed by the terms of service. It was news in 2008 when Google Mobile violated the guidelines to access some useful features. http://daringfireball.net/2008/11/google_mobile_uses_private_iphone_apis http://daringfireball.net/2008/11/google_mobile_uses_private... (Disclaimer: I work for Microsoft, though not on Windows.)
nemeth 14y ago
Windows 8 Metro apps can be written in real C++. How could they sandbox a custom C++ app? There's no virtual machine to do it. http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx http://msdn.microsoft.com/en-us/library/windows/apps/hh46504...
- drivebyacct2 14y ago
  It's C++/CX. It's not just "real C++".
  - contextfree 14y ago
    They can be written in ISO C++ (or if you're a masochist, in C) as well, just without some conveniences.
- barrkel 14y ago
  You don't need a virtual machine to sandbox C++; or rather, there's already a virtual machine in action, in the form of virtual memory and CPU privilege levels. The only way C++ (or any other native language) has to access to the outside its world is through calls to the kernel. Without direct file I/O APIs, options are even more limited (e.g. you can't easily write your own DLL loader).
- msftguy 14y ago
  OS X/iOS use a 'sandbox' driver that utilizes TrustedBSD MAC infrastructure ( https://developer.apple.com/library/mac/#documentation/Darwin/Reference/KernelIOKitFramework/mac_policy_h/index.html https://developer.apple.com/library/mac/#documentation/Darwi... ). Basically, most system calls can be verified against one or more policy modules, and blocked if non-compliant. Not really possible with Windows and its bajillion of syscalls (1000 in win32k alone afair)
- krasin 14y ago
  >How could they sandbox a custom C++ app? There's no virtual machine to do it. They could use NaCl [1] or develop a similar SFI technology just for Windows. [1] http://en.wikipedia.org/wiki/Google_Native_Client http://en.wikipedia.org/wiki/Google_Native_Client
- mkup 14y ago
  Virtual machine is not required for sandboxing C++ apps in 21st century. [1] http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ [2] http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/
  - deleted 14y ago
    [deleted]
- bringking 14y ago
  It may be C++ but it is managed C++ that runs on the above the WinRT layer just like C#, and Javascript for metro. It will have the same restrictions as the other languages. It is actually interesting, in fact when you start a metro project at least in beta, you get the WinRT libraries and that's it. A ton of the traditional .NET classes have been moved into the WinRT library or removed all together.
Someone 14y ago
The problem likely is that part of the public API is in DLLS that use a private API to talk to the system. For example, public class AddressBook extends AddressBookBase, with 'Base' having a couple of private fields that may come in handy. Third parties could figure out that private API and call it themselves. I do not think it is practical to defend the system against thos. Moving that base class into the kernel takes performance and includes its own security risks. Shipping multiple versions of the OS with different layouts or even implementations for such subclasses might help a bit, but also would open the system for bugs that show up on only 1/N of the machines.
contextfree 14y ago
The sandbox (AppContainer) and the SDK API restrictions are two separate things. Capabilities and isolation are enforced by the AppContainer, not the set of available APIs. AppContainer is actually a general system feature that can be used by desktop apps too to sandbox plugins and such (IE10 uses it in "Enhanced Protected Mode").

riffraff 14y ago

isn't it the same that happens on iOS ?

rbanffy 14y ago
Doesn't look like that: http://www.apple.com/iphone/business/docs/iOS_Security_Mar12.pdf http://www.apple.com/iphone/business/docs/iOS_Security_Mar12...
dpark 14y ago
Yes, this is exactly the same (or at least awfully similar). iOS has some APIs that are technically available to 3rd parties, but disallowed by the terms of service. It was news in 2008 when Google Mobile violated the guidelines to access some useful features. http://daringfireball.net/2008/11/google_mobile_uses_private_iphone_apis http://daringfireball.net/2008/11/google_mobile_uses_private... (Disclaimer: I work for Microsoft, though not on Windows.)

nemeth 14y ago

Windows 8 Metro apps can be written in real C++. How could they sandbox a custom C++ app? There's no virtual machine to do it. http://msdn.microsoft.com/en-us/library/windows/apps/hh465045.aspx http://msdn.microsoft.com/en-us/library/windows/apps/hh46504...

drivebyacct2 14y ago
It's C++/CX. It's not just "real C++".
- contextfree 14y ago
  They can be written in ISO C++ (or if you're a masochist, in C) as well, just without some conveniences.
barrkel 14y ago
You don't need a virtual machine to sandbox C++; or rather, there's already a virtual machine in action, in the form of virtual memory and CPU privilege levels. The only way C++ (or any other native language) has to access to the outside its world is through calls to the kernel. Without direct file I/O APIs, options are even more limited (e.g. you can't easily write your own DLL loader).
msftguy 14y ago
OS X/iOS use a 'sandbox' driver that utilizes TrustedBSD MAC infrastructure ( https://developer.apple.com/library/mac/#documentation/Darwin/Reference/KernelIOKitFramework/mac_policy_h/index.html https://developer.apple.com/library/mac/#documentation/Darwi... ). Basically, most system calls can be verified against one or more policy modules, and blocked if non-compliant. Not really possible with Windows and its bajillion of syscalls (1000 in win32k alone afair)
krasin 14y ago
>How could they sandbox a custom C++ app? There's no virtual machine to do it. They could use NaCl [1] or develop a similar SFI technology just for Windows. [1] http://en.wikipedia.org/wiki/Google_Native_Client http://en.wikipedia.org/wiki/Google_Native_Client
mkup 14y ago
Virtual machine is not required for sandboxing C++ apps in 21st century. [1] http://code.google.com/p/nativeclient/ http://code.google.com/p/nativeclient/ [2] http://www.cl.cam.ac.uk/research/security/capsicum/ http://www.cl.cam.ac.uk/research/security/capsicum/
- deleted 14y ago
  [deleted]
bringking 14y ago
It may be C++ but it is managed C++ that runs on the above the WinRT layer just like C#, and Javascript for metro. It will have the same restrictions as the other languages. It is actually interesting, in fact when you start a metro project at least in beta, you get the WinRT libraries and that's it. A ton of the traditional .NET classes have been moved into the WinRT library or removed all together.

Someone 14y ago

The problem likely is that part of the public API is in DLLS that use a private API to talk to the system. For example, public class AddressBook extends AddressBookBase, with 'Base' having a couple of private fields that may come in handy. Third parties could figure out that private API and call it themselves. I do not think it is practical to defend the system against thos. Moving that base class into the kernel takes performance and includes its own security risks. Shipping multiple versions of the OS with different layouts or even implementations for such subclasses might help a bit, but also would open the system for bugs that show up on only 1/N of the machines.

contextfree 14y ago

The sandbox (AppContainer) and the SDK API restrictions are two separate things. Capabilities and isolation are enforced by the AppContainer, not the set of available APIs. AppContainer is actually a general system feature that can be used by desktop apps too to sandbox plugins and such (IE10 uses it in "Enhanced Protected Mode").