How to perform High security tasks from a low level security app??

Discussion in 'Windows Vista Security' started by GSLockwood (IUnknown), Nov 13, 2006.

  1. Hello,

    In other threads, I've seen recommendations to in order to circumvent the
    vista permissions dialogs that they build their .net application with a
    manifest in a particular way.

    How to do the equivalent from C++?

    Is there a "manifest" technique?

    A special COM solution?

    Special Registry settings (set during install -while enjoying admin rights)


    I've created a COM exe with a method that implements CreateProcess. And
    successfully call this from an IE7 app while running in Protected Mode.


    How to do this in other places than IE??

    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company
     
    GSLockwood (IUnknown), Nov 13, 2006
    #1
    1. Advertisements

  2. GSLockwood (IUnknown)

    Jimmy Brush Guest

    Hello,

    In this case, the app that you run from CreateProcess should also be running
    in IE7 protected mode, unless you are using the new interface in IE7 that
    prompts the user for consent in order to "break out" of protected mode.

    Vista is designed so that apps running in different privilege levels are
    seperated, and whenever a lower-privileged application wants to start or
    interact with a higher-privileged one, user consent is required. I.E.
    protected-mode IE requires user consent to launch a non-protected-mode app
    or access things that are restricted from protected-mode.

    In the same vein, when a user wants to start a program that requires admin
    permission, user consent is required unless the program that is wanting to
    start the elevated program is an elevated program itself.

    So, following this abstraction, the correct way to implement your
    application, assuming it only needs admin permission to do certain, specific
    tasks and can be run without admin permission most of the time (kind of like
    windows explorer), is to seperate out the chunks that need admin permission
    into seperate COM components or exe's, and only call/launch them when
    necessary.

    When launching these secondary processes, you will need to programatically
    specify that they need admin permission (or in the case of an EXE, you can
    embed a special manifest that tells Windows it needs admin) and then it will
    prompt the user for permission and elevate the COM/exe so that it can do its
    admin tasks.

    Or, if your entire application is say a systems utility that needs admin
    permission just to run, you should embed a manifest into the app specifying
    that it always needs admin access, and the system will automatically prompt
    the user for permission and give the app admin access every time it is run,
    without you needing to do anything programatically (more on that later).

    Here's a good document that explains this sort of thing:

    http://msdn.microsoft.com/windowsvi...l=/library/en-us/dnlong/html/AccProtVista.asp


    Now, the other situation you may encounter, is where you need your program
    to be able to perform a task that in and of itself should not need admin
    permssion, but the task must have admin permission to be implemented. For
    example, the act of virus scanning should not require admin permission, but
    implementing the virus scan itself does.

    To do this sort of thing, you should implement a windows service that
    performs these high-level tasks. Your application, running as a standard
    user via UAC, should then call this service using some IPC mechanism to
    perform these high-level tasks.

    NOTE, however, that when implementing a service in this manner, you should
    NOT be allowing your program to specifically do admin-related tasks; I.E.
    you shouldn't make a mechanism using this service to allow your application
    to write to restricted registry keys.

    Your application should NOT be able to "break out of its security box" when
    using your service - and you should take great care to ensure that this is
    not possible. The service ITSELF should be able to do admin-related things
    in order to implement whatever tasks that it needs to do, but this power
    should not 'leak' back out to the application.

    For example, the service may need to access security-restricted things to
    perform its duties (for example, the virus scanner needs to access all files
    regardless of security permissions). But in doing so the service must ensure
    that it does not leak such power to the lower-privileged application using
    its services (i.e. the virus scanner UI running as a standard user should
    NOT be able to use the virus scanning interface to access files it does not
    normally have access to - it should only be able to do abstract virus
    scanning related functions)

    I know this is a very fine distinction, and I hope I have explained it well
    :)

    OK more info on manifests:

    A manifest is simply a Win32 resource that is linked into a program module.
    It is not limited to .NET exe's. The manifest tells Vista how much
    permission your program needs.

    This does not 'bypass' Vista's permission dialogs in any way - it tells
    Windows Vista how much access your program needs to the computer.

    If your program always requires administrator permission, for example, Vista
    will ask the user for permission to start your program every time it is
    started, because the only way for programs to run with admin permissions in
    Vista is thru user consent.

    If your program requires 'as much permission as the user has', then your
    program will NOT prompt the user for permission if they are a standard user
    and will have only standard user permission, but WILL prompt if the user is
    an admin and will have admin permission (again, because apps that use admin
    permission must get user consent).

    Or, if your app never requires admin permission, then it will never prompt
    at all, and never have admin permission.

    More info on manifests:

    http://blogs.msdn.com/shawnfa/archive/2006/04/06/568563.aspx
    (note that step 3 gives instruction on how to embed the .res file into a
    ..net exe - instead of this, use the C++ method of doing this)

    http://msdn.microsoft.com/windowsvi...l=/library/en-us/dnlong/html/AccProtVista.asp
     
    Jimmy Brush, Nov 13, 2006
    #2
    1. Advertisements

  3. Are you saying -in effect- that there is no way to avoid the "permission"
    dialogs if I want to say write to a restricted area of the registry?

    One way of the other, the dialog will appear and require user input?

    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company
     
    GSLockwood (IUnknown), Nov 13, 2006
    #3
  4. GSLockwood (IUnknown)

    Jimmy Brush Guest

    Are you saying -in effect- that there is no way to avoid the "permission"
    Yes, that is correct :).

    Allowing such a 'feature' would break Vista's security model.

    The only exception to this rule is either a windows service or an
    appropriately configured scheduled task - these things run with "admin"
    privileges without prompting the user. However, these things are prohibited
    from showing a user interface to the user - they cannot interact with the
    desktop.
     
    Jimmy Brush, Nov 13, 2006
    #4
  5. Thanks, Jimmy!

    This is close to my needs. Because of a business model, I may be forced to
    continue to use some of the now "restricted-by-Vista" resources. Developing
    a Windows Service that can be called upon remotely (via my own well managed
    and secure method) to write to the reg and CreateProcess might be the
    solution.

    So I gather...I would:

    1. Build the service.

    2. Install, register, and start it during s/w installation (i.e. when admin
    rights are in effect).

    3. Call on the service when I need to perform my special tasks.


    As these are utility tasks, I am fine with the non-UI nature.


    BUT Jimmy, suppose I register a "utility" COM component -when admin rights
    are in effect. My "low" level app creates instance on the COM and then calls
    the methods (to carry out "restricted" tasks)...

    ....would this be an alternative?


    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company
     
    GSLockwood (IUnknown), Nov 13, 2006
    #5
  6. GSLockwood (IUnknown)

    Jimmy Brush Guest

    BUT Jimmy, suppose I register a "utility" COM component -when admin rights
    Again, this a completely acceptable way of doing things, but creating the
    admin COM component would ask the user for permission.

    More info on the COM side of things can be found here:

    https://blogs.msdn.com/vistacompatt...sAdmin-or-CreateElevatedComObject-sample.aspx
     
    Jimmy Brush, Nov 13, 2006
    #6
  7. Hello JB,

    Thanks for your help so far! I've just reread this msg and I'll apologize
    up front for its unpleasant tone!! It's exasperation!

    I have 2 questions for ...

    Suppose an app need to write to the following registry in HKLM:

    "Software\\Microsoft\\Windows\\CurrentVersion\\Telephony\\Locations\\Location"

    and several others. Is it the Vista security model that the developer must
    "collect" all these into a COM object, make a call on its method...and the
    user is prompted with the annoying permissions dialog nuisance every time the
    component is called!

    If so, many apps--well behaved and secure in every sense-- will appear to
    the user as malware! This is very unfriendly and frankly wrong!


    Question 2. Windows Service & RPC Solution.
    If I was to create a windows service to handle such cases as you suggest.
    Would the following be true?

    1. I can write the service in C++ (.net is not required).

    2. The service must registered at its time of installation (during an
    administor's session).

    3. The service would start -WITHOUT permission dialogs- at system startup.

    What other special considerations would need to be handled?

    Is there a link devoted to this subject??


    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company
     
    GSLockwood (IUnknown), Nov 16, 2006
    #7
  8. GSLockwood (IUnknown)

    Jimmy Brush Guest

    You're welcome :) No need to appologise, your posts are very well written.

    I believe UAC is prompted when the COM object is instantiated, not on method
    calls.

    But that is correct - you are making a SYSTEM-LEVEL change to the operating
    system. You are doing something that affects both the entire computer and
    other users that use the system. This sort of change REQUIRES admin
    permission. If the user is an admin, they must approve your application to
    do this action. If the user is NOT an admin, they must get permission from
    an admin to take this action.

    I really hope I am making this make sense :).

    The reason you are having so much trouble is because you are trying to do
    something you shouldn't do (bypass user consent).

    Windows has changed (or more precisely, Windows
    is now enforcing something what it has tried to enforce all along). Admins
    now control whether an application has the authority to affect the system
    state or affect other users.
    UAC prompting has nothing to do with whether your program is "good" or "bad"
    -
    and a permission prompt DOES NOT indicate malware! This has to do with
    putting the user in control. Your program, when running inside of a user
    account, has implicit permission to access files/settings that are DIRECTLY
    associated with that user account. If you want to go mucking about with the
    system, your program MUST get permission from an administrator. If the user
    is an admin, then they have to give their permission, because they need to
    know which programs are mucking with their system.

    And, I should point out here, that ALL PROGRAMS are under this same
    restriciton - not just YOURS.

    If someone is wanting to implement a service
    just to bypass UAC and not for a very good reason (and I'm not saying
    you are - I just want to say this here so everyone can see it) --
    I would say to them PLEASE DON'T.
    Doing so would be doing users a grave disservice because allowing
    non-privileged processes to carry out privileged operations
    inevitably allows ANY non-privileged processes to carry out those
    operations (even if the method of invokation is obfuscated or some
    security scheme is attempted, it is impossible to prevent - if this weren't
    so, then UAC would not be necessary in the first place).

    This is a great video on channel 9 that goes more in-depth into the concepts
    of UAC that you may wish to view:

    http://channel9.msdn.com/Showpost.aspx?postid=255622

    Well, it doesn't HAVE to be registered at this time, but it would make the
    most sense. It must be registered by a program that is running with
    administrator privileges.
    I will try and find some more information for you.
     
    Jimmy Brush, Nov 17, 2006
    #8
  9. Jimmy,

    Thanks for your comments and advice.


    I believe the intent of MS is worthy. My concern lies with the IMPRESSION
    the users will feel when they get the permission dialogs. "What is going
    on?", "What is this application doing (that is so 'dangerous' to merit this
    window)?", and such.

    My apps write to hardward registry keys that windows uses (as well) so it
    looks like I'm stuck with a lousy user experience or the windows service
    solution.


    I am wondering if you know a link to a (VS2005) window service project ? I
    have written on but it doesn't stop properly. It would be great to have a
    bare bones skeleton service project (not just for this UAC issue, but for
    completely unrealted, future projects).


    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company



     
    GSLockwood (IUnknown), Nov 17, 2006
    #9
  10. GSLockwood (IUnknown)

    Jimmy Brush Guest

    I believe the intent of MS is worthy. My concern lies with the IMPRESSION
    Well, it is a big deal to give a program administrative access to the
    computer. It's your company's job to make sure the user understands what you
    are doing with this power. For example, Windows Explorer uses this security
    model - you can see it in action when trying to delete/copy files to
    restricted areas. It will first pop up an informational window telling you
    exactly what's going on and that it needs your permission - and then when
    the user clicks continue, a real UAC prompt is issued.

    This is the way all applications that require admin-power will work in the
    future. Most will use this Windows-explorer style elevate-when-needed model,
    but some will always ask the user for permission when the program starts and
    run entirely as admin.

    My point here being, your application will look normal by issuing these
    prompts in the Windows Vista world. It would look abnormal if it didn't
    issue the prompts.
    I don't know the details of your application, so I can't recommend anything
    here. But, if your application only needs to write into this restricted area
    every so often (like when the user changes a setting), using the 'lousy'
    user experience is the best way to go. However, if this is something that
    needs to be modified constantly, your program is not an admin tool, and it
    runs every time the computer starts, then I can understand wanting to put
    that functionality into a service.
    This article looked pretty interesting, but I haven't tested the code:

    http://weblogs.asp.net/kennykerr/archive/2004/05/18/134342.aspx

    Also, if you do decide to implement the service, here's some tips:

    1) Put all the logic that affects admin-related stuff in the service.

    For example of what NOT to do:

    // Any user-mode program can use your service to access HKLM!
    HRESULT WriteStringValueToHKLM(char *subkey, char *name, char *value)
    {
    RegOpenKey(HKEY_LOCAL_MACHINE, subkey, ...);
    ...
    }

    Better:

    // This function doesn't directly expose access to the registry - it only
    allows turning
    // on/off pre-defined values.
    HRESULT ModifySetting(int settingId, bool on)
    {
    RegOpenKey(HKEY_LOCAL_MACHINE, SettingIdToSubkey(settingId), ...);
    ...
    }

    (And, in this example, if you are storing the list of settings that can be
    turned on/off in a config file, MAKE SURE the config file is
    security-restricted so that only administrators [or the user your service
    runs under] have read/write access to it, and everyone else no access :)

    2) Windows Vista allows you to lock down your service so it only has access
    to the bare minimum resources that it needs in order to function. Use this
    feature! If your service only needs access to 3 registry keys, don't give it
    access to ANYTHING else; this way, if there's a bug in your service (or it
    leaks privileges) someone exploiting it won't be able to uber-harm the
    user's computer.

    You can even specify to Windows that your service should only have access to
    certain files/registry keys/etc that expliclty grant that service access
    (which would be set during setup), and no more.

    Unfortunately, I am unable to find developer documentation for this feature;
    they should be somewhere in that windows sdk though :)

    Good luck
     
    Jimmy Brush, Nov 17, 2006
    #10
  11. Thanks JB,

    As developers we have a early view of Vista and its security. It remains to
    be seen how the consumers will react.

    I think Microsoft is betting that users will complain and then comply /
    accept. But deep in their hearts they will not understand / know enough
    about what the security permissions are doing and resent all the new dialogs.

    thanks for the advice about proper service usage AND the link. My service
    was looking a bit like the "bad" example and so I'll try the more OOP
    design...


    --
    Thanks so much,

    george

    _________________________
    George S. Lockwood
    Lead Client Developer
    peoplePC, an EarthLink company



     
    GSLockwood (IUnknown), Nov 17, 2006
    #11
  12. GSLockwood (IUnknown)

    Jimmy Brush Guest

    Do you really think so? I don't. But you're right, it is too early to tell.
    And I'm sure some users will agree with you.

    But remember this: The users that don't like UAC can turn it off. When UAC
    is turned off, your program will NOT PROMPT users. (For example, you could
    implement the COM solution, and when UAC is turned off, instantiating the
    com component as admin will work silently and not throw a permission
    prompt).

    Although UAC seems like its just a hassle, it really does offer users
    powerful control over their computer. Most programs don't need admin
    permissions. The ones that really do, can just ask for permission when
    necessary. Only a very few programs will need admin permission on startup.

    This translates into very few admin permission boxes for the majority of
    users (by the time most apps get ported/patched ... granted this could take
    a while) - which means teaching users how to handle them is possible. Not to
    mention the innumerable security benefits of applications finally being
    rearchitected to work in a least-privileged scenario.

    In your statement here, you are forgetting the users that want their systems
    to be secure. And the users that like UAC and want it turned on (and YES
    they are out there, they are here in this newsgroup [not just me ;)] and I
    have seen them other places as well).

    Following the correct programming model by using UAC will allow your program
    to work in BOTH of these situations: UAC ON will prompt users, UAC OFF will
    NOT prompt users. This is a win-win scenario.

    Because, as you said, you DON'T know how this thing is going to take off ...
    why hedge your bets?

    OK, I'm done trying to convince you. I tried my best, and I have enjoyed
    this discussion :)

    Good luck with your application.
     
    Jimmy Brush, Nov 18, 2006
    #12
  13. These registry keys are restricted for a reason and only administrators
    should change them. Windows currently doesn't offer SUID so in order for an
    administrator to pre-approve the action you must unfortunatly create a
    window service or com+ application. I would think a COM+ app running as a
    service user would be easier as you can delegate the authentication and
    authorization tasks to the COM+ system. But if you write a windows service
    you must becareful about who else might be able to use this service, you
    don't want to just open a tcp port to the world that accepts a simple text
    message "change setting key <value>" even if it is restricted to just the
    Location setting, the administrator should have full knowedge of not only
    what system settings can be changed but also by whom and is entrusting you
    to block all unauthorized users, guets/remote users. This is why I wish
    windows had SUID because it is far to complicated for administrators to
    pre-approve administrative tasks such as yours and if implemented
    incorrectly could create potential exploits for hackers.

    - Kurt


     
    Kurt Harriger, Nov 25, 2006
    #13
    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.