Linked by Dan Massameno on Wed 4th May 2011 21:28 UTC
Permalink for comment 472013
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2008-07-22
You’re totally right. Having a subset of the OS packaged into the application means with 50 Drawbridge applications installed on one system you would have to potentially patch 50 OS sub-systems. Nightmare.
Thankfully, it probably will not be that bad.
1. Vulnerabilities exposed in an app should not be reachable if the app is not running. The attack surface is limited to those apps that are actually executing.
2. Patching all those Win32 subsystems will hopefully be automated with tools.
3. If a particular app doesn’t need 98% of the OS subsystem, those unused parts could be pruned off prior to distributing it to the end-users. Would this be something the developer could do or would it take a team of engineers familiar with the underlying guts of the OS to pull off? I don’t know. Hopefully the former (with automated tools).
4. Remember, this is only a stopgap solution. The real goal is to roll out an entirely new OS that is MUCH more secure (among other tangible benefits, I’m sure). Drawbridge could then be used to supply backward compatibility during a transition period (i.e. 20 years). During that time, our core OS would be much more secure but our Drawbridge apps would be no better off, but no worse off.
Edited 2011-05-06 11:37 UTC