locked
CoImpersonateClient() across Integrity Levels RRS feed

  • Question

  • Hello all,

    I have an app that runs elevated that talks to an unelevated app via COM.
    I want the COM servers in the unelevated app to be able to impersonate the
    elevated client to perform certain file operations with full admin rights.

    Whatever CoInitializeSecurity() parameters I have been trying to apply on
    the client does not give the server appropriate rights ending with
    ERROR_BAD_IMPERSONATION_LEVEL error when it tries to work with a file after
    CoImpersonateClient() call.

    I can foresee that something like a Mandatory Label SACL needs to be applied
    to the client, but I cannot find any documentation in that regard.

    Anyone has any ideas?

    Thanx in advance,
    AlexC
    Tuesday, January 23, 2007 5:48 PM

Answers

  • It's not possible. Processes can only impersonate tokens of lower or equal IL.
    If the low integrity process was compromised, allowing impersonation of a greater IL token would compromise that IL.
    The client would not be able to control what the server does under impersonation.

    Thursday, January 25, 2007 2:28 AM

All replies

  • That's probably because you're getting an Identify level token after impersonation, which is what happens when the caller does not have the juice to impersonate the client.
    The server can query properties of the resulting token, but not act on its behalf...

    Why would the privileged client trust a less privileged server to act on its behalf anyway (it's kind of giving carte blanche)?
    You probably should turn this around, and have the less privilege process call back into the more privileged process to perform the admin operations. The server can then decide if it allows the operation...

    Tuesday, January 23, 2007 6:59 PM
  • So, can anyone confirm that this is not possible at all?

    Our application design does not allow to make such changes and it is OK that the elevated process can trust unelevated COM server, IMHO. I believe that there should be means to make impersonation work across ILs.

    Wednesday, January 24, 2007 4:33 PM
  • It's not possible. Processes can only impersonate tokens of lower or equal IL.
    If the low integrity process was compromised, allowing impersonation of a greater IL token would compromise that IL.
    The client would not be able to control what the server does under impersonation.

    Thursday, January 25, 2007 2:28 AM
  • OK. Thanx for the confirmation, Eric. At least this is clear.

    Though it still looks as unfortunate thing for COM susbsystem with it already being surrounded by many own security facilities.

    E.g. Win32 User susbsystem provides a similar ability via ChangeWindowMessageFilter() to allow elevated apps recieve messages from unelevated ones.

    Friday, January 26, 2007 1:51 PM
  • Hello,

    We're having a similar problem w/ our libraries that customers are linking into their COM clients. Our library creates a new process, and establishes a private pipe, [CreatePipe()] between it and the new process.  However, once the customers code calls an RPC, (or the server calls back), we cannot write, [WriteFile()], to our private pipe, due to ERROR_BAD_IMPERSONATION_LEVEL.

    In this case, we don't care about the server, we're collecting information and trying to send it to our own "slave" process.  Our library doesn't use COM and frankly doesn't care about it in the slightest, nor do we particularly want do.

    Is there anyway that we can allow the client to write on the pipe while it's operating in the context of the server?  Security Attributes?  DACL?

    Any help will be appreciated.

    --Rich
    Tuesday, May 8, 2007 3:46 PM
  • The most likely reason for this failure is a call to AccessCheck while impersonating at identify level.

    This can happen in the [COM] server if the [COM] client only authorized identification level impersonation (i.e. the server can identify the client but can't do stuff on his/her behalf).

     

    If you trying to open/create an object in such context, it will fail regardless of ACLs.

    Now there's something that doesn't completely make sense here, which is that the failure happens during WriteFile.

    WriteFile takes a handle in, and no AccessCheck occurs in that path. It happened at CreateFile time.

    Is it really the WriteFile that fails? Was the handle opened with write permissions?

     

     

    Thursday, May 24, 2007 1:29 AM