Does virtualization imply no ACCESS_DENIED errors ?

[Saurav Ghosh]

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]

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

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

 

[Roger Abell [MVP]]

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

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

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

 

[Soumik Sarkar]

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.

 

[Saurav Ghosh]

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]

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.

 

[Guest]

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.

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

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

 

[Pierre Szwarc]

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" <[email protected]> a écrit dans le message de (e-mail address removed)...
|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.

 

[Guest]

Does that make a keylogger less damaging because it only monitors my account?
I've gotten used to running as a standard user and for the majority of my
daily activities I don't need to be an administrator and fast user switching
means I don't even need to logout for most administrative tasks. Now given
that most users do in fact login as an administrator account (shame) the
users virtual environment rather then the system enviornment will be modified
limiting the damage to that specific user. However if the user is not an
administrator the system suddenly becomes far less secure, such as a domain
user running using a corporate desktop the user now has the power to
overwrite administratively defined group policy settings, etc... whats up
with that? Sure it may only affect that user but thats not the point the
administrator defined a policy perhaps to protect corporate data or even
protect users from themselves (there are always some users that could care
less about security, consistantly download stuff from the internet that it at
times becomes necessary to protect the users from themselves and the
corporate data they work with so that IT can spend less time monitoring and
more time being productive). This functionality makes a previously
non-administrative account more powerful and less secure. IMHO should not be
enabled by default (ie most secure setting should be the default), espeically
on enterprise edition, home edition I could care less but corporate admins
shouldn't need to learn about virtualization because some user did something
that he wans't theoretically allowed to do.
If enabled and the system detects an application attempts an operation that
would ordinarily result in an access denied error the user should be prompted
(as an elevation of privilage to perform a task that normally requires
administrative rights) in the same way administrator is prompted before
invoking an administrative privilage before allowing virtulization to occur,
if virtualization is not approved access should be denied. The system can
save the process location and assicuated hash to remembering the preference
in the future, providing that there is a method to review and modify
preferences. I thought I had read somewhere they plan on removing
virtualization from the next version of windows, and its just a stepping
stone until poorly written apps can be updated, but if it happens silently
whose even going to know the app doesn't follow recommended practices. IMHO
the minimum the need to do is disable by default and prompt first time per
application it is required, the ability to run apps in different virtual
environments and fine tuning of what can be done with in the virtual
environment is perhaps overkill if only a stepping stone, I expect an IT
administrator that uses group policies and other adminstrative controls to
disable this functionality as it is completely unnecessary if one knows how
to fine tune ACLs and grant the necessary file and registry permissions where
required for these legacy applications.

- Kurt

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" <[email protected]> a écrit dans le message de (e-mail address removed)...
|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.