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?