does virtualization imply no access denied errors

Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.

First off, yes, when the file and/or registry virtualization is in effect, Windows is succeeding the operations being requested. (Yet prevents the "real" system from being compromised by the operations, by redirecting the creates & writes to the virtualized location.)
(Note I've been confused on this topic, because the rules for code running inside Internet Explorer are somewhat different than regular applications, and can return failure by design under situations you might have otherwise assumed would have succeeded via virtualization.)
What I can't answer is "where should the application write settings and information that _are_ expected to be shared across all users". For files is probably clear that the same CSIDL_COMMON_APPDATA folder that existed prior to Vista is the right location, but where an application should write registry information common to all users that all users are expected to be able to modify is less clear.
In the whitepaper and "best practice" guide information thus far, I believe the answer to your "legacy application" question is that any application attempting to write to [HKEY_LOCAL_MACHINE\Software] or other protected areas like "\Program Files\" is, within this context, a "legacy application".
Because an "application designed for Vista" would not have attempted to do these things, and would have written to a user-specific area instead. Virtualization is needed to allow all existing "legacy" applications to successfully proceed without error (yet still keeping the "real" Windows locations "protected"), otherwise too many applications would be failing on Vista.
From what I can tell, the intended manner for a Vista application developer to identify their application is doing something that is requiring virtualization is via the Application Verifier / Application Compatibility Toolkit for Vista. Which to my knowledge does not exist yet, but is expected to be part of the Vista and/or SDK beta at some point. There have also been documented references to "logging" of virtualization being available, but not specifically how or where.
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp
Security in Longhorn: Focus on Least Privilege http://msdn.microsoft.com/library/en-us/dnlong/html/leastprivlh.asp
Understanding and Working in Protected Mode Internet Explorer http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp
"Saurav Ghosh" wrote:

Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.

Alan Adams

Alan,
This is more "gut feel" comments on your uncertainty about the virtualization of data intended for all user access. I believe this is outside of the scope of / intent of this virtualization, which is to my awareness always writing the virtualized values on a per account basis. If an account is supposed to be able to write data for all users the system will reflect that and virtualization will not come into play. If it does not then the persistance should be for only that account, since the system says impact on all accounts should not be allowed. Again, this is a gut feel response, but it is based on a few talks over the past year and a half with some of the folks that came up with virtualization.
Roger
"Alan Adams" wrote in message

First off, yes, when the file and/or registry virtualization is in effect, Windows is succeeding the operations being requested. (Yet prevents the "real" system from being compromised by the operations, by redirecting the creates & writes to the virtualized location.)
(Note I've been confused on this topic, because the rules for code running inside Internet Explorer are somewhat different than regular applications, and can return failure by design under situations you might have otherwise assumed would have succeeded via virtualization.)
What I can't answer is "where should the application write settings and information that _are_ expected to be shared across all users". For files is probably clear that the same CSIDL_COMMON_APPDATA folder that existed prior to Vista is the right location, but where an application should write registry information common to all users that all users are expected to be able to modify is less clear.
In the whitepaper and "best practice" guide information thus far, I believe the answer to your "legacy application" question is that any application attempting to write to [HKEY_LOCAL_MACHINE\Software] or other protected areas like "\Program Files\" is, within this context, a "legacy application".
Because an "application designed for Vista" would not have attempted to do these things, and would have written to a user-specific area instead. Virtualization is needed to allow all existing "legacy" applications to successfully proceed without error (yet still keeping the "real" Windows locations "protected"), otherwise too many applications would be failing on Vista.
From what I can tell, the intended manner for a Vista application developer to identify their application is doing something that is requiring virtualization is via the Application Verifier / Application Compatibility Toolkit for Vista. Which to my knowledge does not exist yet, but is expected to be part of the Vista and/or SDK beta at some point. There have also been documented references to "logging" of virtualization being available, but not specifically how or where.
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp
Security in Longhorn: Focus on Least Privilege http://msdn.microsoft.com/library/en-us/dnlong/html/leastprivlh.asp
Understanding and Working in Protected Mode Internet Explorer http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp
"Saurav Ghosh" wrote:
Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.
Alan Adams

A legacy app in this case is an app which is not "runas Administrator" and not marked as requiring admin privileges (either using the app compatibility database or a app manifest) If such an app tries to write to an administrator only location - say Program Files then virtulization kicks in.
Virtualization does not happen when you explicitly run the app as an admin.
When virtualization does happen, files are redirected to c:\Users\<name>\AppData\Local\VirtualStore\ and registry is redirected to HKU\<SID>\Software\Classes\VirtualStore So, one way you can check if virtualization is hapenning is to check the above two areas.
HTH Soumik.
On Tue, 07 Mar 2006 00:47:48 -0800, Saurav Ghosh wrote:

Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

So, any application, irrespective of when it was created, will see its writes succeed, when it tries to write inside "Program Files" or "Windows" directories ? Is there a way to turn off this behavior (only for this app) so that it fails instead of succeeding ?
If not that, is there a way to check if a write operation was successful due to virtualization kicking in lieu of having sufficient privileges ?
Thanks, Saurav.
"Soumik Sarkar" <soumikUNDERSCOREsarkarATyahooDOTcom> wrote in message

A legacy app in this case is an app which is not "runas Administrator" and not marked as requiring admin privileges (either using the app compatibility database or a app manifest) If such an app tries to write to an administrator only location - say Program Files then virtulization kicks in.
Virtualization does not happen when you explicitly run the app as an admin.
When virtualization does happen, files are redirected to c:\Users\<name>\AppData\Local\VirtualStore\ and registry is redirected to HKU\<SID>\Software\Classes\VirtualStore So, one way you can check if virtualization is hapenning is to check the above two areas.
HTH Soumik.
On Tue, 07 Mar 2006 00:47:48 -0800, Saurav Ghosh <sauravg@gmail.com wrote:
Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.


-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

The best way to find such errors is to forget vista and run your app in the context of a normal user on XP. Remember, UAP just tries to emulate a standard user - even for admin users on vista.
Soumik.
On Thu, 09 Mar 2006 21:37:28 -0800, Saurav Ghosh wrote:

So, any application, irrespective of when it was created, will see its writes succeed, when it tries to write inside "Program Files" or "Windows" directories ? Is there a way to turn off this behavior (only for this app) so that it fails instead of succeeding ?
If not that, is there a way to check if a write operation was successful due to virtualization kicking in lieu of having sufficient privileges ?
Thanks, Saurav.
"Soumik Sarkar" <soumikUNDERSCOREsarkarATyahooDOTcom> wrote in message A legacy app in this case is an app which is not "runas Administrator" and not marked as requiring admin privileges (either using the app compatibility database or a app manifest) If such an app tries to write to an administrator only location - say Program Files then virtulization kicks in.
Virtualization does not happen when you explicitly run the app as an admin.
When virtualization does happen, files are redirected to c:\Users\<name>\AppData\Local\VirtualStore\ and registry is redirected to HKU\<SID>\Software\Classes\VirtualStore So, one way you can check if virtualization is hapenning is to check the above two areas.
HTH Soumik.
On Tue, 07 Mar 2006 00:47:48 -0800, Saurav Ghosh <sauravg@gmail.com wrote:
Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.


-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

-- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

I have mixed feelings about this file/registry virtualization. Actually I think this is INSANE!. UAP is aimed at making administrative accounts into limited user accounts to prevent unknowingly granting a process administrative rights where virtualization appears to grant every process a "virtual administrative privilege" within the context of the user account only, in effect all the ACLs are [virtually] disabled allowing application to replace system registry settings and program files that would ordinarily result in an access denied error. Does the left hand know what the right is doing? I don't get it. Personally I don't care if the application enables outlook scripts and macros only for my user account or replaces internet explorer with a look-alike that records usernames and passwords for my user account only. IMHO this is a big mistake and effectively grants the user all the necessary permissions to completely trash his [virtual] environment leading to a new class of malware eventually forcing the administrator to delete his user profile and recreate it from scratch and with more and more applications installed in this virtual environment it might become almost as much work to reinstall your applications and reconfigure your preferences as it is today after a fresh install of windows XP. I don't think virtualization does anything to protect the user rather the only thing that's being protected here is the system which is overshadowed and hidden by the user's virtual environment where every process [virtually] has administrative permissions, so what exactly have we gained by this?
Perhaps I'm missing something here, and hopefully its not as bad as I think it is, but IMHO virtualization should be considered nearly equivalent to granting administrative privileges and thus only be granted with explicit user permission much like UAP. Additionally I think each virtualized application needs to be isolated, perhpas some sort of "virtual process domain" (something like IIS appdomains where multiple applications can share an appdomain, such as the main applicaiton and a configuration tool, but are otherwise isolated from other appdomains) and going further the virtual process domain should have a associated virtual user account (ie file and registry virtualization right in local security policy or something like that) which is used when the user runs an application in that process domain (somewhat like administrator having a split token) thus allowing ACL permissions to be refined as necessary for that virtual process domain, such as virtual user and own new program files folders but not modify existing ones not created by that virtual user thus minimizing the risk that the application might attempt to replace and launch a fake internet explore when user clicks on a link on an application within that process domain for example.
"Alan Adams" wrote:

First off, yes, when the file and/or registry virtualization is in effect, Windows is succeeding the operations being requested. (Yet prevents the "real" system from being compromised by the operations, by redirecting the creates & writes to the virtualized location.)
(Note I've been confused on this topic, because the rules for code running inside Internet Explorer are somewhat different than regular applications, and can return failure by design under situations you might have otherwise assumed would have succeeded via virtualization.)
What I can't answer is "where should the application write settings and information that _are_ expected to be shared across all users". For files is probably clear that the same CSIDL_COMMON_APPDATA folder that existed prior to Vista is the right location, but where an application should write registry information common to all users that all users are expected to be able to modify is less clear.
In the whitepaper and "best practice" guide information thus far, I believe the answer to your "legacy application" question is that any application attempting to write to [HKEY_LOCAL_MACHINE\Software] or other protected areas like "\Program Files\" is, within this context, a "legacy application".
Because an "application designed for Vista" would not have attempted to do these things, and would have written to a user-specific area instead. Virtualization is needed to allow all existing "legacy" applications to successfully proceed without error (yet still keeping the "real" Windows locations "protected"), otherwise too many applications would be failing on Vista.
From what I can tell, the intended manner for a Vista application developer to identify their application is doing something that is requiring virtualization is via the Application Verifier / Application Compatibility Toolkit for Vista. Which to my knowledge does not exist yet, but is expected to be part of the Vista and/or SDK beta at some point. There have also been documented references to "logging" of virtualization being available, but not specifically how or where.
Developer Best Practices and Guidelines for Applications in a Least Privileged Environment http://msdn.microsoft.com/library/en-us/dnlong/html/AccProtVista.asp
Security in Longhorn: Focus on Least Privilege http://msdn.microsoft.com/library/en-us/dnlong/html/leastprivlh.asp
Understanding and Working in Protected Mode Internet Explorer http://msdn.microsoft.com/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp
"Saurav Ghosh" wrote:
Hello,
From Vista documentation, it seems whenever an application tries to write inside a protected part of the filesystem, virtualization will kick in and the write would succeed, through redirection. Does that mean all writes inside "Program Files" etc. would always succeed, and the application in question would never get the ACCESS_DENIED error it deserves ? Wouldn't that prevent developers/testers from finding out such problems in the first place ?
If virtualization is only meant for "legacy applications", how would Vista decide whether an application is a legacy software (and therefore virtualization should kick in), or a Vista compatible one (so it should get the ACCESS_DENIED error) ?
Thanks, Saurav.
Alan Adams

I think you *are* indeed missing the point: virtualization allows the user to mess with system settings without actually breaking the system. Yes, it *is* the OS that's protected by virtualization. But if you {tr|c}rash the OS, you're left up the proverbial creek without a paddle, so it's a good thing. It just doesn't go far enough IMO, and is done as a resource-consuming kludge in this version of the OS. -- Pierre Szwarc Paris, France PGP key ID 0x75B5779B ------------------------------------------------ Multitasking: Reading in the bathroom ! ------------------------------------------------
"Kurt" a écrit dans le message de news: F42339E4-D013-406E-BEA2-3322ADECDE76@microsoft.com... |I have mixed feelings about this file/registry virtualization. Actually I | think this is INSANE!. UAP is aimed at making administrative accounts into | limited user accounts to prevent unknowingly granting a process | administrative rights where virtualization appears to grant every process a | "virtual administrative privilege" within the context of the user account | only, in effect all the ACLs are [virtually] disabled allowing application to | replace system registry settings and program files that would ordinarily | result in an access denied error. Does the left hand know what the right is | doing? I don't get it. Personally I don't care if the application enables | outlook scripts and macros only for my user account or replaces internet | explorer with a look-alike that records usernames and passwords for my user | account only. IMHO this is a big mistake and effectively grants the user all | the necessary permissions to completely trash his [virtual] environment | leading to a new class of malware eventually forcing the administrator to | delete his user profile and recreate it from scratch and with more and more | applications installed in this virtual environment it might become almost as | much work to reinstall your applications and reconfigure your preferences as | it is today after a fresh install of windows XP. I don't think | virtualization does anything to protect the user rather the only thing that's | being protected here is the system which is overshadowed and hidden by the | user's virtual environment where every process [virtually] has | administrative permissions, so what exactly have we gained by this? | | Perhaps I'm missing something here, and hopefully its not as bad as I think | it is, but IMHO virtualization should be considered nearly equivalent to | granting administrative privileges and thus only be granted with explicit | user permission much like UAP. Additionally I think each virtualized | application needs to be isolated, perhpas some sort of "virtual process | domain" (something like IIS appdomains where multiple applications can share | an appdomain, such as the main applicaiton and a configuration tool, but are | otherwise isolated from other appdomains) and going further the virtual | process domain should have a associated virtual user account (ie file and | registry virtualization right in local security policy or something like | that) which is used when the user runs an application in that process domain | (somewhat like administrator having a split token) thus allowing ACL | permissions to be refined as necessary for that virtual process domain, such | as virtual user and own new program files folders but not modify existing | ones not created by that virtual user thus minimizing the risk that the | application might attempt to replace and launch a fake internet explore when | user clicks on a link on an application within that process domain for | example.