command line UAC

[ghost]

Summary of the new feature/enhancement

start-process -verb runas -filepath "complete path of somefile"

invokes UAC which is GUI based and it does take the credentials input within the secure desktop screen, it's super annoying to work with GUI, when already working in powershell.

as a user, want a completely command line powershell implementation of UAC, which will

(i)let me know the executables full file path and publisher info.
(ii) let choose admin users from within command line.
(iii) take credentials from within command line.
basically what UAC gui does today , but from command line.

[jborean93]

This is not really something that can be done in PowerShell as it's a implementation detail in Windows. For you to elevate your account you need to have an already elevated process to spawn the elevated process itself which is what UAC does. There are definitely workarounds for this as UAC isn't considered a security boundary but they at best a hack or something that already runs as an elevated process.

[ghost]

"For what is UAC and what UAC does" part , I feel tempted give my opinion.

For you to elevate your account you need to have an already elevated process to spawn the elevated process itself which is what UAC does.

no standard user can/does elevate his account.
UAC= running in the context of an entirely different user amongst the admin users, not the current standard user

UAC isn't considered a security boundary but they at best a hack or something that already runs as an elevated process.

depends on the definition of "security boundary". UAC by design does it's job what it's supposed to do. UAC is not supposed to stop injection with already running as system components. "sequential processes chains isolation" is something windows yet has to provide for high or medium IL processes.

There are definitely workarounds for this

if getting help from already running elevate process like : app combat, injection etc. are considered as workarounds then that's by definition not "UAC bypass or workarounds" actually that's by design and windows allows that.

[jborean93]

no standard user can/does elevate his account

The actual step to get the admin token must be done specifically by an account that has the SeTcbPrivilege privilege. This is a highly privileged privilege that is only granted to very specific accounts. The UAC setup is able to run as SYSTEM with this privilege so it can get that linked admin account or logon a new user with the credentials specified in the UAC consent window. If the current user account (what is running in PowerShell) is not an admin and doesn’t have the SeTcbPrivilege it is unable to get that admin token, let alone spawn a new process with that token. There’s nothing the user/PowerShell can about that.

Short of PowerShell implementing a privileged service that runs in the background to handle these requests the only proper way to do this is to use UAC or petition windows to implement what you want.

[iSazonov]

I suppose that even if Windows team makes a console UAC dialog instead of a GUI, a new window will open, which again is not what you want.

[ghost]

no standard user can/does elevate his account

The actual step to get the admin token must be done specifically by an account that has the SeTcbPrivilege privilege. This is a highly privileged privilege that is only granted to very specific accounts. The UAC setup is able to run as SYSTEM with this privilege so it can get that linked admin account or logon a new user with the credentials specified in the UAC consent window. If the current user account (what is running in PowerShell) is not an admin and doesn’t have the SeTcbPrivilege it is unable to get that admin token, let alone spawn a new process with that token.

exactly , that's why no standard user can/does elevate his account. ever.

(i)SeTcbPrivilege= runas in the context of SYSTEM user, owned by SYSTEM only, no admin has access to it. as soon as any admin has SeTcbPrivilege then he is no longer an admin user, he becomes SYSTEM user.

(ii)UAC = runas in the context of a admin user amongs the admin users and creates High IL process, not the current user. also known as SeDebugPriviledge

(iii)standard user forever remains as standard user with his by deafult medium IL, if necessary Low IL/AppContainer.

the only proper way to do this is to use UAC.

until powershell implements completely command line UAC ? then yes.

I suppose that even if Windows team makes a console UAC dialog instead of a GUI, a new window will open, which again is not what you want.

actually it's seems to be the other way around.
because users want to elevate from within the same terminal window, the first thing comes to my mind here is a completely command line UAC. when it's done , then it's windows team's job to implement the same window magic for console otherwise we already can do it today through third party tool as gSudo :)

@iSazonov
are you suggesting that because UAC gui owned by windows team therefore powershell won't implement command line dialog version of this?

[jborean93]

I'm not 100% sure the PowerShell team are wanting to do something like this at all. I'm not part of the team so I could be wrong but historically a lot of the security based changes are very conservative and follow the status quo. It's a massive risk security wise to implement their own service for this purpose and fundamentally goes against the standard Windows model where UAC is used.

Off the top of my head one of the security benefits you loose from going this approach is the fact that the UAC consent box is prompted on the secure desktop to try and avoid nefarious software from interacting with it/reading the input. Having it interactive on an existing command line window breaks this feature.

Put simply I personally doubt PowerShell will implement this at all and think this kind of request is meant to be made against the Windows team which is unrelated to PowerShell. As you said there are 3rd party implementations like gsudo, if you want this functionality then it seems like the common consensus is to just use those.

[iSazonov]

are you suggesting that because UAC gui owned by windows team therefore powershell won't implement command line dialog version of this?

UAC in general is a Windows feature. It's designed to be impossible to get around, but that's what you're asking. :-) Change the system settings as you see fit and be happy. :-)

[ghost]

This issue has been marked as answered and has not had any activity for 1 day. It has been closed for housekeeping purposes.