Re: Does virtualization imply no ACCESS_DENIED errors ?

K

Kurt

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" <[email protected]> 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
>
 

My Computer

P

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 news:
[email protected]...
|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.
 

My Computer

K

Kurt

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

"Pierre Szwarc" wrote:

> 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 news:
> [email protected]...
> |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.
>
>
>
 

My Computer

Top