Console self-elevation

[lazna]

What about to have a way to console self-elevate if needed? Not sure about implementation difficultness, but it will be really usefull.

https://github.com/gerardog/gsudo/blob/master/internals.md

[adoxa]

Hm, maybe. It'd be a simpler version than gsudo, just supporting /n: call @elevate command... would run command elevated in the current console (if I can get it working); call @elevate /n command... in a new window (that's reasonably simple). There'd be no differences otherwise (meaning the current environment would not be inherited, even if it appears to be running in the current console).

[adoxa]

Done. Ended up taking a "hybrid" approach to the environment: variables that exist in the current cmd, but not the elevated cmd, will be added; other variables will be left alone. This is mostly because the current user is not necessarily the elevated user, so I don't want to trample those variables. The elevating process will remain open for 15 minutes after the most recent command starts, so you won't get multiple prompts.

[lazna]

Good job, will test it...

[carlos-montiers]

Really nice @adoxa.
I report that on windows 10 the first time you run the ELEVATE until you not authorize this prompt will appear:

This is because the default uac option:

[adoxa]

Yes, that's what's supposed to happen, isn't it? You run @elevate ..., you get the UAC prompt, the command runs. If you do another @elevate within 15 minutes there is no prompt, as the originally elevated rundll32 remains open for that long.

[lazna]

Original intend of this extension is not to bypass UAC prompt (decrease security level), but to keep elevated process (more specific: its output) in original console window.

[carlos-montiers]

I like the 15 minutes feature, but I think will better have that time customizable, I think with a values of 0 for ask every time authorization, -1 for have authorized until the unload, and a positive integer with the minutes.

[adoxa]

Now that I think about it, it's a major security hole - another process could just wait for it to open then run its own elevated command. I could limit it like gsudo, so only the particular cmd that runs the initial elevation can run subsequent commands without a prompt. Or even extend it, so it must be run from a batch (command line will always prompt) and only that batch will not prompt. There'd be no real need for a time limit at all, unload should be sufficient.

[lazna]

Do the @elevate extension provide exitcode if elevation failed (as gsudo provide 999)?

[adoxa]

Have you tried @elevate /??

[...] Errorlevel will be 60399 if the elevated command failed to run (0xEBEF - Enhanced Batch Elevation Failed).

[lazna]

No, I do not, as en Elevate extension is not yet listed in web documentation, do not expect any other docs. Thanks for point me to this.

Have you tried @elevate /??

[...] Errorlevel will be 60399 if the elevated command failed to run (0xEBEF - Enhanced Batch Elevation Failed).

[carlos-montiers]

@lazna, we are trying to embed all the necessary documentation in the help of the dll itself. When the first version be released the documentation of the site will be the same of the dll with more examples.
By the moment for an easy documentation of this extension:
eb @help @elevate

[carlos-montiers]

The security hole was removed (reduced) by @adoxa in #b11bcc2
Although, I think the ideal should be it not be reduced, but removed.
Maybe is better always ask to the user for the elevation, or make the "remain active for the remainder of the batch" feature has an option ?

[lazna]

The security hole was removed (reduced) by @adoxa in #b11bcc2
Although, I think the ideal should be it not be reduced, but removed.
Maybe is better always ask to the user for the elevation, or make the "remain active for the remainder of the batch" feature has an option ?

I am voting for an option.

Sorry for mess with topic closing, I am still not a friend with github :-/

[adoxa]

I think it's pretty hard to exploit, so I don't see an option as necessary. Although I wouldn't do it as an option, anyway, I'd just remove it and always prompt (run the batch itself elevated to avoid multiple prompts).

The exploit would require knowing the value of the pointer to the current batch file at the first use of @elevate (that's why command line usage always prompts, since then it's always 0; although I guess I could use a proper random number and go back to a timer). You could get it easily enough by hooking cmd, but if you can do that you've already got access.

[carlos-montiers]

Is possible to create a little call helper, that elevate the same batch with same parameters and all?

For use as this:

@Echo Off
If %@IsElevated% Equ 0 (
Call @ElevateMe
Goto :Eof
)

[adoxa]

Might even be able to do all it in the call:

@Echo Off
call @SelfElevate [msg]
rem only executed if admin
rem if not admin the call displays msg (or a default) and goes to EOF itself

[carlos-montiers]

@adoxa I like that. But I'm asking about the msg, maybe we can have two messages, one for explaining that the cmd needs permission and if the user press "Yes", in that case, the elevation is requested, If it failed, the second message is displayed and 'goto :eof' as you proposed. What do you think?

[adoxa]

I'm not sure that's necessary. I'd expect the prompt itself will be enough indication elevation is desired, if that's cancelled the message will indicate that elevation is required.

@echo off
call @selfelevate "This batch requires administrator privileges."
:: Continue if elevated, or stop if the UAC prompt is Yes (running the elevated batch).
:: If the prompt is No stop, outputting the message (that'd be the default) to stderr.

[carlos-montiers]

Mmm, I think you are right. Because can be achieved like this:

@Echo Off
If %@IsElevated% Equ 0 (
Echo This batch needs the authorization to make changes
Pause
Call @selfelevate "This batch requires administrator privileges."
)

Thus, the prior message is displayed in the console if is desired, instead of a prompt.
The authorization is more direct, instead of:
prompt -> press Yes.
Uac -> press Yes.

Also, I'm thinking in the way of the elevation, because EB allows load with rundll32 and regsvr32, maybe is possible to save with which application EB was loaded?. For use the same for request the elevation?. If was loaded with rundll32 request the elevation with rundll32, if it was loaded with regsvr32 request the load with regsvr32.
What do you think about this idea?

[adoxa]

Thus, the prior message is displayed in the console if is desired, instead of a prompt.
The authorization is more direct, instead of:
prompt -> press Yes.
Uac -> press Yes.

I'm not quite sure what you're saying, there. I'm saying the call itself will test for elevation: if it is, it just exits and the batch continues; if not, it will run the batch as admin, which will give you the UAC prompt: if Yes, this batch pauses, runs the elevated version, then exits; if No, the message is displayed and it exits. There is no "instead of a prompt" - unless you're already admin or have disabled UAC you always get the prompt.

If was loaded with rundll32 request the elevation with rundll32, if it was loaded with regsvr32 request the load with regsvr32.
What do you think about this idea?

More work for no benefit.

[carlos-montiers]

Oh @adoxa, now I understand it clearly. Is really a good approach.

[carlos-montiers]

I think for security concerns is better to remove this feature.

[carlos-montiers]

I removed the code for security concerns.

[lazna]

Why do you remove this function without any discussion? I wrote you mail, but you may not read it, so I decide to write here.

[carlos-montiers]

Hello @lazna . The main reason is the number of days without implementation that encourage always request the user approbation. @adoxa Do you think is possible reimplement in a way that always requests the user approbation? Also, I would love to name the extension: @sudosu :)

[adoxa]

It wasn't necessary to remove it altogether, just always prompt. I'll eventually put it back, doing it that way, and adding the self command, so the batch itself is elevated. Don't know when, though.

[lazna]

If it is removed temporary, till adoxa handle security issue, than OK for me.

BTW: In the meantime, author of gsudo solve issue (reported by me) with situation if batch is started from mapped drive. So maybe take it in the account later, when this will be fixed....