Wesley Parish wrote:
"insecure-by-inattention" - by that I mean software that must run as super-user or otherwise (otherstupidly) it won't run at all.
read all you can find on the new security features in Windows Vista. The security model has been enhanced with various forms of Mandatory Access Control - among the many of them, the fact that all users (except System, i.e. services) are entirely powerless by default, even administrators, and a reauthentication is required every time privileges are needed (the user experience is pretty much identical to MacOSX) - and the application compatibility layer has been enhanced to the point it now fully implements a virtual filesystem view and a virtual registry view.
As for per-application sandboxing, it's very possible even today (with restricted tokens) and I use it daily. It has a couple of issues, one of which strictly technical and the others concerning usability. The technical issue is that sandboxes are barred from any form of client-side SSPI authentication - this means no accessing CIFS shares, no integrated authentication to an ISA proxy server, no remote administration through a snap-in, etc. (all attempts to create outbound credentials fail with a spurious "out of memory" error). It's hard to be worked around and presumably it's there for a reason other than "it was too hard to do".
The usability issues are many, many, many. Too many to be contained in a mailing list posting. I think it'd help to describe how an end user should interact with it, and then code whatever hacks are required for it, or rethink the interaction if the hacks prove to be too ugly.
The problem with your approach? too much maintenance. Even for a server. Setup packages for Windows tend to be a mistery, a surprise after another, a gift that keeps giving, can you really tell how to categorize their files and registry keys? and even then, are you sure that'd be a good idea?