Elevated privileges question

[Eric Strain]

Hi All:

I'm new to this list. I am a computer programmer and I'm looking for other programmers that may be able to answer a question for me. I hope this is the right forum for this. I have a question about elevated processes. Say a program executes under an administrator account and as soon as the main process starts, it executes code that elevates its privileges from admin to system level. My question is, does the main process now have system level privileges or does it have to call LogonUser( ) and CreateProcessAsUser( ) in order for all down-level processes to have system level access? At present the only process in the program is the initial one, I have not created any other processes or threads. The program is a simple exe, not a service and it is not impersonating anyone. Any insight would be much appreciated. Thanks guys.

please reply to *SNIP*

-Eric

[LoKz]

:welcome: someone will help eventually :think:

[box]

I'm not an expert, but this is what I think I know.

When you execute a process under Admin (assuming that the Admin has the appropriate permissions), then that process runs under the Admin elevated privileges. (It doesn't bleed over to System.) If that process then execute a secondary process where the Admin also has the appropriate permissions, then there is no need to invoke another lower privileged account to execute a program. An Admin privilege can not invoke a System only privileged process nor can a System invoke an Admin only privileged process.

Think of the Admin and System as two different persons with the same elevated privileges. The Admin is always a human user who has the Admin elevated privileges. The System is always the OS or a program. The Admin can not execute a System process nor can a System execute an Admin process if neither has the appropriate permission. For an Admin to execute a System only process, the Admin account user must first authorize himself the appropriate permissions.

[Eric Strain]

Hi Box,

Thanks for the reply, you're right about a few things, the Admin privileges do not "bleed" over to System and an Admin privileged process can't invoke a process that requires system-level privileges. However, for this project I run my program under an account that is a member of the local administrators group on the machine. That means that under normal circumstances when my program runs, it runs with the same rights and control capabilities that the administrator account has on that machine. When my program first starts, it elevates itself to system level by adding privileges to the administrator SID. Now when the program finishes, my administrator account (that the program is running under) has more capabilities than it had before the privilege elevation. That means that the program can now do things on the machine that even a user with Administrator privileges cannot do. That is the whole point of the program, to test this capability of the "new" privileges. I know that any secondary process that is started in a program inherits the privileges of the calling process, and I'm thinking that in order to initialize any down-level processes (i.e. start another program that will have system-level control over the machine), my elevated process will have to call CreateProcessAsUser( ) and maybe even LogonUser( ). Any thoughts?

-Eric

I'm not an expert, but this is what I think I know.

When you execute a process under Admin (assuming that the Admin has the appropriate permissions), then that process runs under the Admin elevated privileges. (It doesn't bleed over to System.) If that process then execute a secondary process where the Admin also has the appropriate permissions, then there is no need to invoke another lower privileged account to execute a program. An Admin privilege can not invoke a System only privileged process nor can a System invoke an Admin only privileged process.

Think of the Admin and System as two different persons with the same elevated privileges. The Admin is always a human user who has the Admin elevated privileges. The System is always the OS or a program. The Admin can not execute a System process nor can a System execute an Admin process if neither has the appropriate permission. For an Admin to execute a System only process, the Admin account user must first authorize himself the appropriate permissions.

[box]

However, for this project I run my program under an account that is a member of the local administrators group on the machine. That means that under normal circumstances when my program runs, it runs with the same rights and control capabilities that the administrator account has on that machine.

Assuming that the administrator account has the appropriate permissions for that program.

When my program first starts, it elevates itself to system level by adding privileges to the administrator SID.

This is a bleed over. If a program runs under a System account (with appropriate permissions) it stays under System. Adding privileges to the Admin SID is just that. It adds Admin SID to a file, a folder, or a registry key. By adding Admin SID doesn't automatically make a program runs under the Admin account.

This would be a correct statement. When my program first starts, it elevates itself to system level AND adds privileges to the administrator SID.

Now when the program finishes, my administrator account (that the program is running under) has more capabilities than it had before the privilege elevation. That means that the program can now do things on the machine that even a user with Administrator privileges cannot do.

Admin and System are both elevated accounts. With FULL control permission, they can do things equally on a machine. What else is there to do for an Admin with FULL permission?

That is the whole point of the program, to test this capability of the "new" privileges.

Privilege is not the same as Permission. Even an elevated account WITHOUT FULL permission is limited in its privileges.

I know that any secondary process that is started in a program inherits the privileges of the calling process

This is not true. Even an Admin can not invoke a process that it doesn't has permission.

The key in all this is PERMISSION. Being an elevated account is just icing on a cake. What I don't understand is, what additional capabilities do you want this program to add?

[3NIGM4]

Just think of the "privilege" you have to be here :) Isnt "elevating" you lol

[Eric Strain]

This is not true. Even an Admin can not invoke a process that it doesn't has permission.

That's true, BUT when my program finishes running, it has added the privileges to the Administrator account that it is running under so that the account effectively has system-level control over the machine (through the elevated process). I know this because I wrote the program to give itself that power.

Admin and System are both elevated accounts. With FULL control permission, they can do things equally on a machine. What else is there to do for an Admin with FULL permission?

I agree that Admin and System are both elevated accounts (compared to say a guest user), and as for what else there is for an Admin with FULL permission, even an administrator cannot acquire certain process handles or take total control over and debug the memory that is "owned" by another process or user... There are a LOT of things even an administrator with "FULL" permission or privileges can't do on the machine. As an example, there is a powerful privilege called SE_TCB_NAME that allows any process or program that has it to "Act as part of the operating system", in other words, a program that either has, or acquires that privilege can do anything on the machine that the operating system can do. This means it can take control of any file or process on the computer regardless of any OS enforced security measures, (not counting some type of encryption or other physical or digital security measures). this also includes injecting code into other processes on the machine and numerous other powerful things.

Now back to my original question, I was thinking about it and I think I will have to call CreateProcessAsUser( ) and launch the new target process through that function by using a handle to the elevated process. That will allow the other program (a second program that I intend to launch with its new capabilities) to do what it needs to without being restricted by the OS.

However, for this project I run my program under an account that is a member of the local administrators group on the machine. That means that under normal circumstances when my program runs, it runs with the same rights and control capabilities that the administrator account has on that machine.

Assuming that the administrator account has the appropriate permissions for that program.

When my program first starts, it elevates itself to system level by adding privileges to the administrator SID.

This is a bleed over. If a program runs under a System account (with appropriate permissions) it stays under System. Adding privileges to the Admin SID is just that. It adds Admin SID to a file, a folder, or a registry key. By adding Admin SID doesn't automatically make a program runs under the Admin account.

This would be a correct statement. When my program first starts, it elevates itself to system level AND adds privileges to the administrator SID.

Now when the program finishes, my administrator account (that the program is running under) has more capabilities than it had before the privilege elevation. That means that the program can now do things on the machine that even a user with Administrator privileges cannot do.

Admin and System are both elevated accounts. With FULL control permission, they can do things equally on a machine. What else is there to do for an Admin with FULL permission?

That is the whole point of the program, to test this capability of the "new" privileges.

Privilege is not the same as Permission. Even an elevated account WITHOUT FULL permission is limited in its privileges.

I know that any secondary process that is started in a program inherits the privileges of the calling process

This is not true. Even an Admin can not invoke a process that it doesn't has permission.

The key in all this is PERMISSION. Being an elevated account is just icing on a cake. What I don't understand is, what additional capabilities do you want this program to add?

[Eric Strain]

Just think of the "privilege" you have to be here :) Isnt "elevating" you lol

That's funny, I hadn't thought of that. But actually, I think a little friendly confrontation can be helpful sometimes. It forces people to see things from a different perspective, which can lead to new ideas.

[box]

@Eric Strain

Have you seen these articles?

http://support.microsoft.com/kb/180548
http://msdn.microsoft.com/en-us/library/aa378184%28VS.85%29.aspx

According to this article:

Windows XP, 2K, 2K3, Vista, etc.
With the introduction of Windows XP, the requirement to hold the SE_TCB_NAME privilege was removed.

http://www.codeproject.com/KB/system/UserImpersonation.aspx?msg=2794509