Does virtualization imply no ACCESS_DENIED errors ?

Discussion in 'Windows Vista Security' started by Saurav Ghosh, Mar 7, 2006.

  1. Saurav Ghosh

    Saurav Ghosh Guest

    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.
     
    Saurav Ghosh, Mar 7, 2006
    #1
    1. Advertisements

  2. Saurav Ghosh

    Alan Adams Guest

    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

    Alan Adams
     
    Alan Adams, Mar 7, 2006
    #2
    1. Advertisements

  3. 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

     
    Roger Abell [MVP], Mar 9, 2006
    #3
  4. 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.
     
    Soumik Sarkar, Mar 10, 2006
    #4
  5. Saurav Ghosh

    Saurav Ghosh Guest

    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.
     
    Saurav Ghosh, Mar 10, 2006
    #5
  6. 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.
     
    Soumik Sarkar, Mar 14, 2006
    #6
  7. Saurav Ghosh

    Kurt 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.


     
    Kurt, Apr 4, 2006
    #7
  8. 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 ...
    |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.
     
    Pierre Szwarc, Apr 4, 2006
    #8
  9. Saurav Ghosh

    Kurt 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

     
    Kurt, Apr 5, 2006
    #9
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.