Prev: Coding help for loading custom icons into toolbar
Next: Interesting CreateEvent issue
From: Corinna Vinschen on 24 Feb 2010 12:39
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
From: Joseph M. Newcomer on 24 Feb 2010 13:47
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(a)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(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
From: m on 24 Feb 2010 22:52
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(a)community.nospam> wrote in message
news:hm3o7o$9g1$1(a)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

From: Kerem Gümrükcü on 24 Feb 2010 23:07
Hi Joseph,

thanks for the example, it works
excellent for me,...

K.

--
-----------------------
Beste Gr�sse / Best regards / Votre bien devoue
Kerem G�mr�kc�
-----------------------

From: Joseph M. Newcomer on 25 Feb 2010 00:45
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(a)hotmail.com> wrote:

>Hi Joseph,
>
>thanks for the example, it works
>excellent for me,...
>
>K.
Joseph M. Newcomer [MVP]
email: newcomer(a)flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Coding help for loading custom icons into toolbar
Next: Interesting CreateEvent issue