locked
Decouple security and stability improvements from interface and source restrictions

    General discussion

  • I am really excited about a few of the new features of Metro apps. It has been obvious for many years that treating every process the same as the user who launched it is the main reason why malware is so rampant; that what we need is to sandbox EVERY process, and force it to ask the user for anything it needs outside of the sandbox. I was very excited when the .NET Framework started down this path with CAS, and very disappointed when they ditched CAS in .NET 4; I am glad to see it returning. It is also obvious that the lack of "application" as a first class concept in the operating system is why the system becomes so disorganized so quickly: every custom installer decides where to put files in the file system, what registry entries to create, where to put shortcuts in the Start menu, which uninstallers to register in Programs and Features (I'm looking at you Visual Studio), etc. And of course this also leaves us with a mess when the application is uninstalled: since the application is responsible for cleaning up after itself, and there is basically no incentive to do a good job of that, almost everybody gets it wrong, or at least incomplete.

    So I was nothing short of ecstatic when I first heard that Microsoft was finally stepping up and doing something about these issues in Windows 8. Automatic sandboxing, where applications are forced to ask the user to use anything outside their own installation, is a huge win for security and stability. Package-based installation that confines applications to their own directory and allows them to be completely removed when uninstalled is a big win for system organization. However, that enthusiasm evaporated almost immediately when I found out that these improvements are being confined to Metro apps, which are so restricted as to be completely unusable in any normal desktop environment. This means that a) my applications, and therefore my users, won't be able to take advantage of these new features, and b) I will be forced to continue using applications that also cannot take advantage of them, and will continue to be exposed to the security, stability, and organizational problems that have plagued Windows for two decades.

    Since these improvements, which are so critical to the advancement of the Windows OS, are technically unrelated to the restrictions imposed on Metro apps, I ask that they be completely decoupled, so that the entire Windows ecosystem can take advantage of the improved security, stability, and organization, rather than just a few niche apps that can put up with the Metro restrictions. Specifically:

    1) Allow package installations outside of the Windows Store. This is the most critical point by far. I and my customers have no interest in "sharing revenue" with Microsoft. The Windows Store certification process was presented as being necessary to ensure security, but that is in fact not true: it is the controlled installation and automatic sandboxing that is present in the OS itself that is ensuring security, not the parental oversight of the certification team.

    We have been told that "Enterprise customers and developers" will be able to "side load" packages (although we have been given no details about what that means), but that is not sufficient. ALL users must be able to load whatever packages they choose. The USER must be in control of their system, not Microsoft.

    2) Allow metro apps to run without being full screen. There is no reason why Metro apps shouldn't be able to run in normal windows just like any other application. The USER should be in control of whether they want the app to run maximized, windowed, on the primary, secondary, or tertiary monitory, or overlapping monitors for that matter.

    3) Allow metro apps to run multiple instances. Default to single instance if you want, but allow the app to specify that it can run multiple instances. If the user wants to run multiple instances, and the app allows it, why should the system step in and insist that it is not allowed?

    4) Possibly as an alternative to #2 and #3, allow desktop applications to opt-in to package installation and sandboxing, giving the USER the peace of mind that the app cannot harm them while maintaining most of the desired capabilities of a traditional desktop applications. Yes, a lot of desktop applications would have to be modified to ensure that they can operate correctly inside the sandbox. But quality applications probably wouldn't have to be modified much, and it would certainly be worth it to me as both a developer and a user.

    I hope that I am not shouting at the wind, and that this early developer preview release represents more than just Microsoft's desire to get the dissatisfaction out of the way early, but rather a sincere desire to gather, and more importantly incorporate, feedback from their most passionate user base.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    • Edited by David A Nelson Tuesday, September 20, 2011 4:44 PM formatting
    Tuesday, September 20, 2011 4:41 PM

All replies

  • Some apps are just not going to work with sandboxing. E.g. backup apps. Antivirus. How could those apps work without accessing to the whole system? You can argue document editor apps need to be sandbox too with the cloud as the storage but putting document in the cloud could be against federal regulation e.g. HIPAA.

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Tuesday, September 20, 2011 8:35 PM
  • 1) Anti-virus would have to continue to be desktop only, since by definition it is invasive to the whole system. On the other hand, if we move entirely to sandboxed apps, we won't have much need for anti-virus, will we?

    2) Backup: sandboxed apps can be given access to specific parts of the file system by the user. So the user can give a backup app permission to access the parts of the file system that need to be backed up, and potentially to the location where the files should be backup up to (if not going to the cloud).

    3) Document editing: again, a sandboxed app is perfectly capable of opening any file in the file system, as long as the user allows access, which they do merely by selecting the file top open.

    And besides, I never said that ALL desktop apps HAVE to be sandboxed today. I said that they should be ALLOWED to opt-in to sandboxing if they want to, giving their users more confidence that they can use the app without fear of harming their system or giving away personal information.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Tuesday, September 20, 2011 8:54 PM
  • Yes, app developers can opt in by rewriting code based on WinRT, but whether they choose to support WinRT is their choice, not Microsoft's. Microsoft had a hard time just to get app developers stop writing configurations into the program files folder. 

    And even if app developers upgraded the apps, their users may not want to upgrade (think about how many users are still using VC6 or Office 2003).

    Sandboxing is not bug-free. Besides, social engineering can trick the users to give more permission than they actually need to. Antivirus won't die because of sandboxing. 

    Besides, sometimes the document editor/viewer is not the one who decide where document should be stored, and for how long. Many companies have compliance officers just to make sure the way they store document is compliment with laws and regulations.

     

     



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Tuesday, September 20, 2011 9:09 PM
  • You seem to be not be understanding or completely ignoring the point of my posts.

    1) App developers can NOT opt in "by rewriting code based on WinRT", precisely because WinRT is so (needlessly) limited. I want sandboxing, but I am not going to run every app in full screen to get it. That is in fact the entire point of this post in the first place, as indicated directly in the title.

    2) "social engineering can trick the users..." I think the need for anti-virus will be massively reduced if we move to a secure-by-default system - i.e. sandboxing - rather than an open-by-default system. And I want Microsoft to encourage developers to move that way by allowing ALL applications, not just severely restricted Metro apps, to opt in to sandboxing.

    3) "the document editor/viewer is not the one who decide where document should be stored..." Quoting from my previous post: "...a sandboxed app is perfectly capable of opening any file in the file system, as long as the user allows access..." I don't understand why you keep bringing this up: it's a non-issue.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Tuesday, September 20, 2011 9:37 PM
  • WinRT is a run time, you cannot magically opt-in a runtime without rewriting code. Think about throwing a exe to CLR, it won't understand a bit of it unless the exe contains IL code specifically written for the runtime. If you watched the keynote, you would see a picture with metro app in green on the left and desktop apps in blue on the right, with WinRT and Win32/.Net/Silverlight as their base. From the picture, desktop apps do not overlap with WinRT. Of course nothing is set on stone yet, you can still appeal to Microsoft to let them change the plan.

    The need to fully control the system exists since, well, forever. Even when you have sandbox in other mobile OSes you still have users to find every possible security venerability to jailbreak or root. The need for antivirus never cease to exist when the same security venerability can also be exploited to infect the system. 

    I was looking at the RoamingStorageQuota property that may force apps to store data in the cloud. I was wrong, local apps do not have such quota.

     



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Tuesday, September 20, 2011 11:16 PM
  • I didn't ask for WinRT. I asked for opt-in sandboxing. They don't have to be the same thing; there is no reason why the existing Win32 APIs couldn't be modified for sandboxing (think UAC, but, you know, not sucky).

    OR, make WinRT useful. That's #2 and #3. I am fine with that. If sandboxing Win32 directly is seen as too hard or too risky, that's fine. Leave sandboxing only in WinRT; but then make sure that WinRT can actually be used to write real programs. Currently it can't. I want sandboxing. I really really do. I think it will revolutionize the stability and security of modern computing and will forever change user's impressions of the Windows OS. But only if it actually gets used, and in it's current state, it won't. As badly as I want sandboxing, I am not going to run every single application as a single instance in full-screen all the time. That's just not going to happen. Which is - again - why I have asked in the title of this post for the ability to sandbox to be decoupled from the needless restrictions currently being imposed on Metro apps.

     

    The issue of anti-virus is really a completely different discussion. I already said that anti-virus programs would NOT opt-in to the sandbox. However, I have yet to see a system where malware could force a jailbreak or root from inside a sandbox. The user typically has to break the system's sandbox first before malware can get in. And they usually only do that because the sandbox is around the entire system (e.g. the iPhone), limiting user functionality and giving the user incentive to break it. If the sandbox is implemented correctly, isolating each individual process but not limiting user control of the system, then the user will have much less incentive to break it. Sandboxing might not be perfect, but if everything on my system were individually sandboxed, I would definitely not be willing to sacrifice my system performance to an anti-virus program that has an infinitesimal chance of ever actually being useful. Although frankly I think most anti-virus programs are already near useless IF the user has some basic common sense. Which most users don't.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 3:33 PM
  • sandboxing in win32 is mostly done by antivirus. That's part of the reason why they can't be sandboxed. This is for uses who, of cause, do not like running as a normal account or turn on UAC to benefit from the OS's built-in security protection and is OK with performance sacrifcation. 

    A venerability that can cause complete access to the system (whether for jailbreak or for infection) is a venerability nevertheless. And  because it can be useful for jailbreak, it gets publicity.

    "most uses don't have some common sense" is self-contradictory. You can't just give up the 95% user base who does not even know how to change a setting.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Wednesday, September 21, 2011 4:25 PM
  • "sandboxing in win32 is mostly done by antivirus"

    Now you have completely lost me. I opened the post with some very specific recommendations and my justification for them. You have taken the conversation in a direction that doesn't in any way actually address my recommendations, and now are making statements that don't even seem to be relevant to the conversation.

    To restate my original recommendations in the simplest possible terms: I want USEFUL sandboxing. Currently, sandboxing is only available in WinRT, and WinRT is not useful. I want one of those things to change.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 4:34 PM
  • Sorry, but we can disagree on what is useful. Most people do not wear armor when they go outside. For occasional dirt cloth is enough. An armor may be useful if you work in the army, but if not useful for basically everyone else. You need to estimate the risk before the government manufacture armor for everyone so they can opt-in the armor. 

    We can agree to disagree on what the security should be, it is not up to what you or me think, it is up to the security providers, and ultimately, the risk posed by hackers, and how much people are willing to spend on their protection, and how much freedom they are willing to give up. Are you that worry with threats possed by your app? After all, you wrote all the code. If you want you can run your app in low IL like IE's protected mode does.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP

    Wednesday, September 21, 2011 4:49 PM
  • "it is not up to what you or me think, it is up to the security providers"

    Excuse me? The security of my system is most certainly NOT up to third party "security providers". Do you work for a security vendor? That is the only way I can imagine someone making such a statement.

    The system should be secure by default. All users should have the confidence that an app can not harm their system or access any data unless the user says it can. That's not about "wearing armor", it's about locking your front door and only letting in those you want to let in. And it's not a new or difficult concept; it's been around for a long time, but Microsoft is just now getting around to implementing it. But as long as WinRT is as useless as it is right now, most apps won't be written to take advantage of it, which means that users won't actually see any benefit from it. Which - yet again - is the purpose of my original suggestion.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 6:42 PM
  • Sorry I failed to see who are you arguing for. If you are a developer, you need to fix security venerability in your app instead of throwing the problem to someone else. Venerabilities like buffer overrun are or dereferencing wild pointers not just security threat but also can cause the app to be unstable and the user's data to be corrupted. If you save to somewhere accidentally where you should not have to, then it is a bug.

    If you are a user, then avoid software that has security venerability but refuse to fix and say "The OS will take care of it".



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Wednesday, September 21, 2011 8:12 PM
  • "avoid software that has security venerability"

    Great idea! And how would you suggest that I, as an end user, determine whether an app has a security vulnerability? Or whether it is discretely stealing my data? Why would I want the OS to throw open the doors to any application that happens to be running and let it do whatever it wants? Why should I as the user not have the control to TELL the system what an application is or isn't allowed to do?

    I am truly flabbergasted that you are actually arguing that sandboxing is a BAD thing. We clearly have different goals. I want my system to be secure by default while still allowing me flexibility and control. My proposals above are designed to push toward that goals. I am not sure what you goal is.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 8:38 PM
  • I said "If you are a user, then avoid software that has security venerability but refuse to fix." Looks you removed the last part.

    If I were a developer, I don't want to pay a performance penalty to not fix stuff that not only can cause my app to be an attack factor, but also cause my app to look bad (crash, corrupt the user's data).  

    Of course, unwanted software will not opt-in sandboxing, the whole point of their existence is to infect the system. Thus your argument is moot.



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP

    Wednesday, September 21, 2011 8:47 PM
  • You're right, I misread the part about refusing to fix security vulnerabilities. My point stands though, that apps can easily have security vulnerabilities that I as a user have no way of knowing about.

    I have not seen any evidence that sandboxing actually creates a measurable performance penalty independent of the effect of simply running on whatever the underlying runtime is. Do you have evidence to support that?

    "Of course, unwanted software will not opt-in sandboxing"

    Now you're making my argument for me. A huge part of the value in sandboxing is changing the culture around what is and isn't allowed to run on an computer. Right not everything is allowed the run of the house. By changing the culture of the Windows ecosystem so that everything is sandboxed by default, it will be much easier to notice the apps that aren't playing by the rules. We can focus our scrutiny on the apps that refuse to be sandboxed, while being confident that everything else is secure (or as secure as we can get it). Moreover, I can teach my technically illiterate mother that if its sandboxed (almost certainly not using that term of course), she can install it; if it isn't she can't. If there is something she really wants to install that isn't sandboxed, she can call me first. That's a really easy rule for her to remember, and I AND SHE would much rather that than for me to have to sweep her computer every two weeks to get rid of all of the crap on it because she can't tell what's safe and what isn't. A similar argument can be made for corporate environments.

    It's all about giving control of the PC back to the user. In the current environment, even technology professionals and power users often have no idea what is running on their system and what it is doing. By moving the entire Windows ecosystem towards sandboxing, we eliminate that uncertainty. But that will only happen IF we can convince most applications to use sandboxing, which will only happen IF sandboxed applications still have the same user interface capabilities that current desktop applications have (among other things). There is no technical reason why that can't happen; Microsoft simply has to enable it.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 9:33 PM
  • Because, well, if a programmer knows a security vulnerability exists, the reaction would be to fix the cause, not to declare "I need a babysitter". 

    If you want a sand boxing in the OS regardless what developers do. Then why you think programmers need to opt-in or opt out?

    Forcing everyone rewrite their app to run in the sandbox does not make the need of antivirus go away. It only give the users a false sense of security. Think about it, without antivirus, the bad guys now have a single target to crack, instead of having to sneak through all kinds of antivirus software. This would greatly reduce the cost of their development and QA process. 



    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Wednesday, September 21, 2011 10:07 PM
  • 1) Allow package installations outside of the Windows Store. This is the most critical point by far. I and my customers have no interest in "sharing revenue" with Microsoft. The Windows Store certification process was presented as being necessary to ensure security, but that is in fact not true: it is the controlled installation and automatic sandboxing that is present in the OS itself that is ensuring security, not the parental oversight of the certification team.

    2) Allow metro apps to run without being full screen. There is no reason why Metro apps shouldn't be able to run in normal windows just like any other application. The USER should be in control of whether they want the app to run maximized, windowed, on the primary, secondary, or tertiary monitory, or overlapping monitors for that matter.

    3) Allow metro apps to run multiple instances. Default to single instance if you want, but allow the app to specify that it can run multiple instances. If the user wants to run multiple instances, and the app allows it, why should the system step in and insist that it is not allowed?

    4) Possibly as an alternative to #2 and #3, allow desktop applications to opt-in to package installation and sandboxing, giving the USER the peace of mind that the app cannot harm them while maintaining most of the desired capabilities of a traditional desktop applications. Yes, a lot of desktop applications would have to be modified to ensure that they can operate correctly inside the sandbox. But quality applications probably wouldn't have to be modified much, and it would certainly be worth it to me as both a developer and a user..


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com


    1) The use of a centralised repository for software has been demonstrated over and over again to provide users with a simpler and safer mechanism for installing software. You see this on pretty much every platform now and it's something Linux users having been citing as one of the main downsides of Windows for years. With Apple moving to an integrated store for Mac OS X as well as iOS, not providing this would leave Windows in a seriously disadvantaged position. Furthermore a centralised app store offers a great opportunity for smaller developers to gain global exposure in a way that is simply impossible in a distributed model without having to become specialists in international tax laws and sales regulations.

    The app store also provides an opportunity to scan the applications prior to install to ensure they aren't calling out to APIs that would allow them to break the sandbox model. Without that, the sandboxing is entirely ineffective which runs contrary to what you (and everyone else) wants from Windows applications.

    Finally having a centralised repository of all applications makes it much easier to restore a machine to the users desired state in the event something catastrophic happens to their PC. It also makes roaming between multiple machines extremely easy.

    2) Actually there is a really good reason and it's probably why there is not WinRT desktop apps story (at the moment). WinRT applications have a system managed lifecycle. They are suspended when they aren't in-use and the system will simply clear them from memory should it need to reclaim memory. They are also designed to provide a fully immersive environment, utilising the PC hardware to the full. Neither of these can be translated to the desktop environment, particularly when they would need to coincide with applications that have a user-managed lifecycle.

    3) When you have full screen, immersive applications it doesn't really make logical sense to run "multiple instances", because you are by definition only ever interacting with one Metro application at a time. If it makes sense for an application to do so they can provide tab like functionality as seen in Metro IE or take advantage of the panorama control to provide side-by-side views as seen in the weather app. They can even (with user permission) create secondary tiles on the Start screen to expose alternate data via their Tile or to give quick access to a specific data view.

    4) That requires significant work to provide a consistent model for desktop applications to allow them to run in a sandboxed environment, as well as solving any number of challenging issues with how to best support things like the application lifecycle model without over-constraining desktop applications to be less useful and without creating a confusing user experience when combined with legacy applications. I have no doubt we will see this in a future release of Windows, but I suspect it's too large a scope to be viable in this release. Windows 8 represents one of the most significant restructuring of the operating system in years already and expecting a complete replacement for Win32 to occur in a single product release is probably too much to be practical.

    Wednesday, September 21, 2011 11:07 PM
  • 1) I never said the App Store wasn't a good idea, or that Microsoft shouldn't do it, or that users shouldn't use it. I said it should be optional. If a developer and his user are willing to pay Microsoft a premium for whatever services the store provides, they can. But they shouldn't have to. This is about keeping the USER in control. If the user wants to install a package that they download off my website, they should be able to. Since it is still a package-based installer and the process will be sandboxed, it is still just as inherently safe as installing something from the store.

    "The app store also provides an opportunity...to ensure they aren't calling out to APIs that would allow them to break the sandbox model. Without that, the sandboxing is entirely ineffective..."

    No it isn't; in fact, scanning is basically worthless in a sandboxed environment, since an app that attempts to break the sandbox will fail at runtime. Which is fine; if the app is buggy, the user can uninstall it. No harm done.

    "Finally having a centralised repository of all applications makes it much easier to restore a machine to the users desired state in the event something catastrophic happens to their PC. It also makes roaming between multiple machines extremely easy."

    There is no reason that the package itself couldn't be uploaded to the user's profile so that it could be restored or installed on a different machine. But if there is concern that would require too much bandwidth or storage space or whatever, then that's fine: tell the user when they install the app that it will not be restored and will not be available when they are roaming. The USER should be allowed to make that decision, not Microsoft.

    2) What does a system-managed lifecycle have to do with multiple windows?

    3) As I already said in #2, Metro apps should NOT always be full screen. That aside, full screen and multiple instances are completely orthogonal; I am not sure why you are conflating them. Yes, an app CAN go to a lot of extra effort to provide multiple independent instances of their interface from inside the application, with the necessary additional navigation elements, etc. But why should it have to? Why not just say to the user "launch it again" and be done with it?

    4) I didn't ask for a complete Win32 replacement. I asked, if WinRT is going to be so horribly hobbled, that Win32 alllow sandboxing. This is not technically complicated: any runtime call that accesses restricted resources and hasn't been pre-cleared by the user fails at runtime. UAC proved it was possible, but got the implementation horribly wrong. That doesn't mean it couldn't be done better. And again, I never said that every single desktop application has to be sandboxed. I said that desktop applications should be able to opt-in to sandboxing, which would give their users greater confidence that they can be used safely.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 11:37 PM
  • I feel like I'm banging my head against the wall.

    I never said I wanted sandboxing in the OS regardless of what developers do. I said an application should be able to opt-in to sandboxing in order to give users more confidence that it can be used safely. I feel like that is a really easy concept.

    The entire industry has been moving towards secure by default for at least two decades. Most of the rest of the industry is a lot farther along than Microsoft is; Windows is just catching up. The purpose of my suggestions was to help get Windows there faster. If you don't accept the inherent value in a secure by default system, then there really isn't much else for us to discuss.


    Moderator | MCTS .NET 2.0 Web Applications | My Blog: http://www.commongenius.com
    Wednesday, September 21, 2011 11:40 PM