Create non-elevated process from elevated process,...?

Hi, i am looking for some way to execute some application of my chioce from an elevated process. This is )for sure) no problem, but the problem is that i want to execute the newly spawned process as a non elevated process without the elevated token rights of the same user. I already tried this by using this, but it is not a realiable solution since it depends on a running shell/explorer process. http://blogs.msdn.com/aaron_margosis/archive/2009/06/06/faq-how-do-i-start-a-program-as-the-desktop-user-from-an-elevated-app.aspx Does someone have a good idea, possibly not something with a second process runing non-elevated and expecting some signal or antother IPC data to spawn the non-elevated process, or like the example above duplicating the token from a process,... Thanks on advance,... K. -- ----------------------- Beste Gr�sse / Best regards / Votre bien devoue Kerem G�mr�kc� -----------------------

Hi Kerem, On 2/24/2010 9:42 AM, Kerem G�mr�kc� wrote: > Hi, > > i am looking for some way to execute some application > of my chioce from an elevated process. This is )for > sure) no problem, but the problem is that i want to > execute the newly spawned process as a non elevated > process without the elevated token rights of the same user. > I already tried this by using this, but it is not a realiable solution > since it depends on a running shell/explorer process. > > http://blogs.msdn.com/aaron_margosis/archive/2009/06/06/faq-how-do-i-start-a-program-as-the-desktop-user-from-an-elevated-app.aspx > > > Does someone have a good idea, possibly not > something with a second process runing non-elevated > and expecting some signal or antother IPC data to > spawn the non-elevated process, or like the example > above duplicating the token from a process,... > > Thanks on advance,... > > K. > I think the answer is given in the article you mentioned: Since you want the process to run under the same user account as the elevated process, but just run it without the elevation, then "launch the new process with that �dumbed down� token". Have you tried creating a restricted token from your elevated token and then use CreateProcessAsUser? I have never tried this but I assume this is the way to go. -- S

On Feb 24, 8:42=A0am, Kerem G=FCmr=FCkc=FC <kareem...@hotmail.com> wrote: > I already tried this by using this, but it is not a realiable solution > since it depends on a running shell/explorer process. As an aside for others, the comments in the article you linked to have what looks like a better method of doing this, if you don't mind the requirement that the shell/explorer is running: http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-f= or-you-part-2-how/ It gets an interface to Explorer.exe, which should be running in the user's normal context, and asks Explorer to execute a command in its behalf. This is done just using simple, documented COM interfaces and without having to mess around with process tokens or code/DLL injection. I'm guessing you need this to work in environments where the shell might not be running, though... To do it without any dependency on the shell/explorer, I think you have to either manipulate the token yourself (not easy) or split your process into elevated and non-elevated halves, where the elevated side can ask the non-elevated side to launch things on its behalf. (You can use various IPC methods for that conversation.) Of course, you then have to run your non-elevated side somehow, but often that is easy. (e.g. If your app is being run from an non- elevated context and currently requesting elevation at startup, have it instead start the non-elevated part at startup and have that run the elevated part itself via a UAC prompt.) It's quite a shame there still isn't a proper API for creating the medium or low integrity level token given a higher one. This question keeps coming up and it's been a glaring hole in the UAC API since day one.

On Feb 24, 9:42=A0am, Kerem G=FCmr=FCkc=FC <kareem...@hotmail.com> wrote: > Hi, > > i am looking for some way to execute some application > of my chioce from an elevated process. This is )for > sure) no problem, but the problem is that i want to > execute the newly spawned process as a non elevated > process without the elevated token rights of the same user. Perhaps something on the lines of OpenProcess/ThreadToken, then CreateRestrictedToken, then CreateProcessAsUser could work? Goran.

Hi Stefan, Hi Leo, yes, i need to do this even without any explorer process running, thats the point, unless that, it is no big match to run the code from the Shell Token,... Regards Kerem ----------------------- "Leo Davidson" <leonudeldavidson@googlemail.com> schrieb im Newsbeitrag news:4c6568a1-e1ca-4638-9a6e-78235c592cd5@v25g2000yqk.googlegroups.com... > On Feb 24, 8:42 am, Kerem G�mr�kc� <kareem...@hotmail.com> wrote: >> I already tried this by using this, but it is not a realiable solution >> since it depends on a running shell/explorer process. > > As an aside for others, the comments in the article you linked to have > what looks like a better method of doing this, if you don't mind the > requirement that the shell/explorer is running: > > http://brandonlive.com/2008/04/27/getting-the-shell-to-run-an-application-for-you-part-2-how/ > > It gets an interface to Explorer.exe, which should be running in the > user's normal context, and asks Explorer to execute a command in its > behalf. This is done just using simple, documented COM interfaces and > without having to mess around with process tokens or code/DLL > injection. > > I'm guessing you need this to work in environments where the shell > might not be running, though... > > To do it without any dependency on the shell/explorer, I think you > have to either manipulate the token yourself (not easy) or split your > process into elevated and non-elevated halves, where the elevated side > can ask the non-elevated side to launch things on its behalf. (You can > use various IPC methods for that conversation.) > > Of course, you then have to run your non-elevated side somehow, but > often that is easy. (e.g. If your app is being run from an non- > elevated context and currently requesting elevation at startup, have > it instead start the non-elevated part at startup and have that run > the elevated part itself via a UAC prompt.) > > It's quite a shame there still isn't a proper API for creating the > medium or low integrity level token given a higher one. This question > keeps coming up and it's been a glaring hole in the UAC API since day > one.

Stefan Kuhr wrote: > Hi Kerem, >=20 > On 2/24/2010 9:42 AM, Kerem G=C3=BCmr=C3=BCkc=C3=BC wrote: >> Does someone have a good idea, possibly not >> something with a second process runing non-elevated >> and expecting some signal or antother IPC data to >> spawn the non-elevated process, or like the example >> above duplicating the token from a process,... >=20 > I think the answer is given in the article you mentioned: Since you wan= t=20 > the process to run under the same user account as the elevated process,= =20 > but just run it without the elevation, then "launch the new process wit= h=20 > that =E2=80=9Cdumbed down=E2=80=9D token". >=20 > Have you tried creating a restricted token from your elevated token and= =20 > then use CreateProcessAsUser? I have never tried this but I assume this= =20 > is the way to go. CreateRestrictedToken works fine, but there's a warning in MSDN that CreateRestrictedToken is still a bit of a security problem: "Warning Applications that use restricted tokens should run the restricted application on desktops other than the default desktop. This is necessary to prevent an attack by a restricted application, using SendMessage or PostMessage, to unrestricted applications on the default desktop. If necessary, switch between desktops for your application purposes." Other than that, I experimented a lot with GetTokenInformation info class TokenLinkedToken, and as far as I remember, if you're running in an elevated process, the linked token is the non-elevated token. So, in theory, if I remember right, what you could do is this, just roughly outlined: TOKEN_LINKED_TOKEN linked; TOKEN_TYPE type; token =3D OpenProcessToken (GetCurrentProcess ()); if (!GetTokenInformation (token, TokenLinkedToken, &linked)) /* bail out */ new_token =3D linked.LinkedToken; if (GetTokenInformation (linked.LinkedToken, TokenType, &type) && type !=3D TokenPrimary) { /* Ok, that's a bit tricky now. If the linked token is the elevated token, and if the process running this code does not have TCB privs, then the linked token is an impersonation token *and* DuplicateTokenEx fails when trying to create a primary token from this impersonation token. However, that doesn't mean it won't work for the non-elevated token. */ if (!DuplicateTokenEx (linked.LinkedToken, ... TokenPrimary, &new_token)) /* bail out */ } CloseHandle (token); CreateProcessAsUser (new_token, ...); If it doesn't work..., well, maybe it was worth a try? Corinna --=20 Corinna Vinschen Cygwin Project Co-Leader Red Hat

Explorer is irrelevant to this. All you need to do is create a token with restricted access. First suggestion: google for SECURITY_MANDATORY_MEDIUM_RID but here's the code I show in my course on Systems Programming: HANDLE token; if(!OpenProcessToken( GetCurrentProcess(), MAXIMUM_ALLOWED, &token)) ...deal with error HANDLE duplicate; if(!DuplicateTokenEx(token, // existing MAXIMUM_ALLOWED, // desired NULL, // security SecurityImpersonation, TokenPrimary, // for CreateProcessAsUser &duplicate)) // new token ... deal with error PSID IntegrityLevelSid = NULL; CString SIDvalue; // S-revision-authority-rid // S-1-16-? // 16 represents // SECURITY_MANDATORY_LABEL_AUTHORITY SIDvalue.Format(_T("S-1-16-%d"), SECURITY_MANDATORY_MEDIUM_RID); if(!ConvertStringSidToSid(SIDvalue, &IntegrityLevelSid)) ...deal with error TOKEN_MANDATORY_LABEL IntegrityLevelToken = {0}; IntegrityLevelToken.Label.Attributes = SE_GROUP_INTEGRITY; IntegrityLevelToken.Label.Sid = IntegrityLevelSid; if(!SetTokenInformation(duplicateToken, TokenIntegrityLevel, &IntegrityLevelToken, sizeof(TOKEN_MANDATORY_LABEL) + GetLengthSid(IntegrityLevelSid))) ...deal with error LocalFree(IntegrityLevelSid); if(!CreateProcessAsUser(duplicateToken, ..., // program name ..., // command line NULL, // process attributes NULL, // thread attributes FALSE, // no inheritance 0, // flags NULL, // inherit environment NULL, // inherit directory &startupinfo, &processinfo)) ...deal with error On Wed, 24 Feb 2010 09:42:06 +0100, Kerem G�mr�kc� <kareem114@hotmail.com> wrote: >Hi, > >i am looking for some way to execute some application >of my chioce from an elevated process. This is )for >sure) no problem, but the problem is that i want to >execute the newly spawned process as a non elevated >process without the elevated token rights of the same user. >I already tried this by using this, but it is not a realiable solution >since it depends on a running shell/explorer process. > >http://blogs.msdn.com/aaron_margosis/archive/2009/06/06/faq-how-do-i-start-a-program-as-the-desktop-user-from-an-elevated-app.aspx > >Does someone have a good idea, possibly not >something with a second process runing non-elevated >and expecting some signal or antother IPC data to >spawn the non-elevated process, or like the example >above duplicating the token from a process,... > >Thanks on advance,... > >K. Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm

this risk exists as soon as there are both elevated and non-elevated processes running on the same desktop, since they must communicate to maintain basic state, and what you would need to do has little impact on the overall security of the system since you are already running an elevated process, and just talking about starting a restricted one. This note just reinforces the fact that the elevated / restricted token is not a hard security barrier, but just another layer in a layered defence "Corinna Vinschen" <corinna@community.nospam> wrote in message news:hm3o7o$9g1$1@perth.hirmke.de... > Stefan Kuhr wrote: >> Hi Kerem, >> >> On 2/24/2010 9:42 AM, Kerem Gümrükcü wrote: >>> Does someone have a good idea, possibly not >>> something with a second process runing non-elevated >>> and expecting some signal or antother IPC data to >>> spawn the non-elevated process, or like the example >>> above duplicating the token from a process,... >> >> I think the answer is given in the article you mentioned: Since you want >> the process to run under the same user account as the elevated process, >> but just run it without the elevation, then "launch the new process with >> that “dumbed down” token". >> >> Have you tried creating a restricted token from your elevated token and >> then use CreateProcessAsUser? I have never tried this but I assume this >> is the way to go. > > CreateRestrictedToken works fine, but there's a warning in MSDN that > CreateRestrictedToken is still a bit of a security problem: > > "Warning Applications that use restricted tokens should run the > restricted application on desktops other than the default desktop. > This is necessary to prevent an attack by a restricted application, > using SendMessage or PostMessage, to unrestricted applications on > the default desktop. If necessary, switch between desktops for your > application purposes." > > Other than that, I experimented a lot with GetTokenInformation info > class TokenLinkedToken, and as far as I remember, if you're running in > an elevated process, the linked token is the non-elevated token. > > So, in theory, if I remember right, what you could do is this, just > roughly outlined: > > TOKEN_LINKED_TOKEN linked; > TOKEN_TYPE type; > > token = OpenProcessToken (GetCurrentProcess ()); > if (!GetTokenInformation (token, TokenLinkedToken, &linked)) > /* bail out */ > new_token = linked.LinkedToken; > if (GetTokenInformation (linked.LinkedToken, TokenType, &type) > && type != TokenPrimary) > { > /* Ok, that's a bit tricky now. If the linked token is the > elevated token, and if the process running this code does not > have TCB privs, then the linked token is an impersonation token > *and* DuplicateTokenEx fails when trying to create a primary > token from this impersonation token. However, that doesn't mean > it won't work for the non-elevated token. */ > if (!DuplicateTokenEx (linked.LinkedToken, ... TokenPrimary, > &new_token)) > /* bail out */ > } > CloseHandle (token); > CreateProcessAsUser (new_token, ...); > > If it doesn't work..., well, maybe it was worth a try? > > > Corinna > > -- > Corinna Vinschen > Cygwin Project Co-Leader > Red Hat

The code is a synthesis of about three examples I found a couple years ago when I had to do this, because VS2005 had to run elevated on Vista, and I needed to run my code at normal integrity level (the "medium" is where most programs run). Since the whole point of the program was to make sure it ran at normal integrity, the first thing it did was check its integrity level, and if it wasn't normal, it re-launched itself at normal integrity. joe On Thu, 25 Feb 2010 05:07:59 +0100, Kerem G�mr�kc� <kareem114@hotmail.com> wrote: >Hi Joseph, > >thanks for the example, it works >excellent for me,... > >K. Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm

Hi Joseph, thank you very much for the example. Borrowing the explorers token was not a good idea. Could you pleace send me the examples of the three things you found, that would be great. But i faced another interessting thing: When i start a explorer.exe with the code above and i want to run a executable that has a manifest asking for UAC,...the UAC does not come up and there ia also no shield overlay on the icon of the executable. How can this be explained or do you have an explanation for this,... K.

Hi Corinna, On 2/24/2010 6:39 PM, Corinna Vinschen wrote: > Stefan Kuhr wrote: >> Hi Kerem, >> >> On 2/24/2010 9:42 AM, Kerem Gümrükcü wrote: >>> Does someone have a good idea, possibly not >>> something with a second process runing non-elevated >>> and expecting some signal or antother IPC data to >>> spawn the non-elevated process, or like the example >>> above duplicating the token from a process,... >> >> I think the answer is given in the article you mentioned: Since you want >> the process to run under the same user account as the elevated process, >> but just run it without the elevation, then "launch the new process with >> that “dumbed down” token". >> >> Have you tried creating a restricted token from your elevated token and >> then use CreateProcessAsUser? I have never tried this but I assume this >> is the way to go. > > CreateRestrictedToken works fine, but there's a warning in MSDN that > CreateRestrictedToken is still a bit of a security problem: > > "Warning Applications that use restricted tokens should run the > restricted application on desktops other than the default desktop. > This is necessary to prevent an attack by a restricted application, > using SendMessage or PostMessage, to unrestricted applications on > the default desktop. If necessary, switch between desktops for your > application purposes." > > Other than that, I experimented a lot with GetTokenInformation info > class TokenLinkedToken, and as far as I remember, if you're running in > an elevated process, the linked token is the non-elevated token. > It definitely is worth a try for Kerem. My experience is that the linked token can only be used for the AccessCheck API and nothing else. However, since GetTokenInformation with TokenLinkedToken still seems to be officially undocumented (my Server 08 PlatSDK doesn't document it and on msdn online, TokenLinkedToken is also not mentioned as a valid parameter for GetTokenInformation), I wouldn't be surprised if it works accidentally but breaks with the next service pack. -- S

Hey Stefan, Stefan Kuhr wrote: > Hi Corinna, > > On 2/24/2010 6:39 PM, Corinna Vinschen wrote: >> Other than that, I experimented a lot with GetTokenInformation info >> class TokenLinkedToken, and as far as I remember, if you're running in >> an elevated process, the linked token is the non-elevated token. > > It definitely is worth a try for Kerem. My experience is that the linked > token can only be used for the AccessCheck API and nothing else. You are definitely right, if the process has no TCB privileges, and if the process token is the restricted token, not the elevated token. In this case the linked token is just an impersonation token and the call to DuplicateTokenEx(PrimaryToken) fails with "access denied". However, I know for a fact (since I'm using this capability in Cygwin) that the linked, elevated token is a primary token suitable for calls to CreateProcessAsUser, if the calling process has TCB privileges. Which makes a lot of sense to me, even if that is nowhere documented. And I seriously hope for Cygwin that this won't be changed in some future version of Windows. In Kerem's case I'm not sure. I never checked in the inverse case - calling TokenLinkedToken on the elevated token - and without TCB privileges, if the linked token is an impersonation token for which DuplicateTokenEx(PrimaryToken) fails. I made the suggestion nevertheless, because it can be very easily tested. > However, since GetTokenInformation with TokenLinkedToken still seems to > be officially undocumented (my Server 08 PlatSDK doesn't document it and > on msdn online, TokenLinkedToken is also not mentioned as a valid > parameter for GetTokenInformation), I wouldn't be surprised if it works > accidentally but breaks with the next service pack. It is documented as TOKEN_INFORMATION_CLASS member: http://msdn.microsoft.com/en-us/library/aa379626%28VS.85%29.aspx And the TOKEN_LINKED_TOKEN structure is documented as well: http://msdn.microsoft.com/en-us/library/bb530719%28VS.85%29.aspx It's only missing in the man pages for GetTokenInformation and SetTokenInformation. The fact that the TOKEN_LINKED_TOKEN man page refers to SetTokenInformation is interesting. I assume that you need TCB privileges as well to link a token to another token, but I never tried that. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat

Hi Corinna, On 2/25/2010 3:38 PM, Corinna Vinschen wrote: > <snip> > In Kerem's case I'm not sure. I never checked in the inverse case > - calling TokenLinkedToken on the elevated token - and without TCB > privileges, if the linked token is an impersonation token for which > DuplicateTokenEx(PrimaryToken) fails. I made the suggestion > nevertheless, because it can be very easily tested. > Were you thinking about something like the following code? When run under an elevated token, CPAU fails with 1314 (Privilige not held) and the linked token is an impersonation token, duplicating it to a primary token fails with 1346 (bad impersonation level): int _tmain(int argc, _TCHAR* argv[]) { TOKEN_LINKED_TOKEN tlt; HANDLE hProcessToken = NULL; if (OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hProcessToken)) { DWORD cbLength = 0L; if (GetTokenInformation(hProcessToken, TokenLinkedToken, &tlt,sizeof(tlt), &cbLength)) { TCHAR szCmdLine[] = _T("notepad"); STARTUPINFO si = {0}; si.dwFlags = STARTF_USESHOWWINDOW; si.wShowWindow = SW_SHOW; PROCESS_INFORMATION pi; if(CreateProcessAsUser(tlt.LinkedToken, _T("c:\\windows\\notepad.exe"), szCmdLine, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS, NULL, NULL, &si, &pi)) { _tprintf(_T("It worked\n")); VERIFY(WAIT_OBJECT_0==WaitForSingleObject(pi.hProcess, INFINITE)); VERIFY(CloseHandle(pi.hProcess)); VERIFY(CloseHandle(pi.hThread)); } else { DWORD dwLastError = GetLastError(); _tprintf(_T("CPAU failed with %lu (0x%.8x)\n"), dwLastError, dwLastError); } TOKEN_TYPE tt; if (GetTokenInformation(tlt.LinkedToken, TokenType, &tt,sizeof(tt), &cbLength)) { _tprintf(_T("Token is of type %lu\n"), (DWORD) tt); if(TokenImpersonation==tt) { HANDLE hPrimary = NULL; if(!DuplicateTokenEx(tlt.LinkedToken, 0L, NULL, SecurityImpersonation, TokenPrimary, &hPrimary)) { DWORD dwLastError = GetLastError(); _tprintf(_T("DuplicateTokenEx failed with %lu (0x%.8x)\n"), dwLastError, dwLastError); } } } VERIFY(CloseHandle(tlt.LinkedToken)); } VERIFY(CloseHandle(hProcessToken)); } return 0; } Cheers, -- S

I found them a couple years ago using google. None of them was quite the best style of programming, so I rewrote them using the best examples from each plus avoiding sprintf. I have long since forgotten where I found them; one was a Microsoft blog site, but I don't remember the other two. The code I showed was the ultimately best-programming-style example. I have no idea how UAC and Explorer work together (or don't, as seems to be your case). My goal was to launch a non-elevated app from an elevated app, which was your original question. I have found that the further I stay away from the explorer, the happier I am. Having once tried to write an explorer extension, the most polite thing I can say is the whole thing is a confused mess. joe On Thu, 25 Feb 2010 07:09:01 +0100, Kerem G�mr�kc� <kareem114@hotmail.com> wrote: >Hi Joseph, > >thank you very much for the example. Borrowing >the explorers token was not a good idea. Could >you pleace send me the examples of the three >things you found, that would be great. But i faced >another interessting thing: When i start a explorer.exe >with the code above and i want to run a executable >that has a manifest asking for UAC,...the UAC does >not come up and there ia also no shield overlay >on the icon of the executable. How can this be >explained or do you have an explanation for this,... > >K. Joseph M. Newcomer [MVP] email: newcomer@flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm

Stefan Kuhr wrote: > Hi Corinna, > > On 2/25/2010 3:38 PM, Corinna Vinschen wrote: >> <snip> >> In Kerem's case I'm not sure. I never checked in the inverse case >> - calling TokenLinkedToken on the elevated token - and without TCB >> privileges, if the linked token is an impersonation token for which >> DuplicateTokenEx(PrimaryToken) fails. I made the suggestion >> nevertheless, because it can be very easily tested. >> > > > Were you thinking about something like the following code? When run > under an elevated token, CPAU fails with 1314 (Privilige not held) and > the linked token is an impersonation token, duplicating it to a primary > token fails with 1346 (bad impersonation level): Yes, exactly. So this is not usable in Kerem's scenario. Too bad. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat