boxstarter broke my Win10 Administrator Privileges

[VinciShark]

Makes my Windows10 PC get Administrator Privileges everywhere.
Never notice me before restart my PC, or let me to choose when to restart to continue.
……
And now? I am reinstalling my Windows10 OS……

[gep13]

@VinciShark sorry to hear that you are having issues. Can you please provide some more information about exactly what you are/were seeing? The information that you have provided isn’t enough to figure out exactly what is/was going on.

[mpeson]

It seems that the installer disables Window's UAC. I'm no security expert but that doesn't seem to be something that any installer should be doing, even if it's meant to be temporary.

Also while messing up the security settings the installer reboots the PC without any warning whatsoever.

[pauby]

@mpeson

Also while messing up the security settings the installer reboots the PC without any warning whatsoever.

Boxstarter is aimed at bootstrapping machines. So when a required reboot is detected it's done. This is documented. If it has to wait on you rebooting the machine then it defeats the purpose.

It seems that the installer disables Window's UAC. I'm no security expert but that doesn't seem to be something that any installer should be doing, even if it's meant to be temporary.

Boxstarter does not disable UAC. There is however a command called Disable-UAC. If the script you ran has that command then it will disable UAC as you said. The responsibility for enabling it again lies with the script creator, not Boxstarter, using Enable-UAC.

UPDATE: Boxstarter does disable UAC. See Matt's explanation.

[VinciShark]

It seems that the script disable my UAC, while it fails to re-enable it.
But don't know why.
It is an entire new Windows10 PC, whithout any strange 【computer housekeeper】

[pauby]

@VinciShark Where did the script come from (I want to ask specifically if it came from NodeJS as we're getting increasing number of issues created because of this)?

[mwrock]

Just want to add a little context/history here. @gep13 pinged me about this general issue in a twitter DM and this seems like the best place to respond. Gary's DM included this twitter thread where these same security concerns were raised and it was pointed out that elevating the process would be a better path than disabling UAC.

These are all totally valid points!

Here is why I added the disable/re-enable UAC behavior rather than taking the normal path of elevating. For those unfamiliar with the mechanics of "elevating" that basically boils down to throwing up the "run as admin" prompt where a user consents to allow the process elevated admin privileges. Boxstarter's primary use case at that time (and I think largely still is) is to allow a user to "bootstrap" their machine with a single command, walk away, go to bed and come back with everything set up as they like. The key dilemma here in terms of UAC and elevation is what to do after a reboot. When Boxstarter reboots the machine, it interactively logs the user back in after the reboot into an interactive windows session. Prior to the reboot, boxstarter saves a script into the user's "startup" folder so that the script kicks off as soon as the new session logs in. However with UAC on, the script will not run as admin and lots of subsequent setup operations will very likely fail. Boxstarter could elevate but that would mean that someone has to "man the helm" which boxstarter never assumes.

So that was the motivation. If I were to implement this all over again I would have done it differently. Instead of putting a script in the "startup" folder (which totally does not work in server core SKU machines), I would have created a scheduled task to run this script upon startup. This way the task would not need an interactive session and could run with elevated privileges without prompting as long as it ran under an admin user's credentials and has a RunLevel set to Highest.

The biggest downside to the task approach is that after a reboot, boxstarter would continue completely unseen. That might be fine if you are away but often (likely in the nodejs case) you are watching the screen and want to have a sense that things are a happening. Also, there are some installers that MUST be run in an interactive context. I think back when I created Boxstarter (2012), I needed a couple apps that had the interactive requirement and today I'd likely say I don't want to have anything to do with an app that has such a requirement :).

I will happily leave it up to the very capable Chocolatey team to decide the best path forward here and wish I had more time to help but at least wanted to give some background into the present state of things.

[andrewtchilds]

Also, there are some installers that MUST be run in an interactive context.

If the vast majority of installers don't require an interactive session, I say it's worth going the task scheduler route (at least by default). Surely there's other ways to give the user the status of their Boxstarter script, at least when they log back in.

As an aside, this is probably part of the reason why MDT uses the built-in Administrator account, where UAC is off, during desktop deployment.

[flcdrg]

Thanks @mwrock for the history and context.

Changing to scheduled tasks is something to consider, but as flagged it probably is a breaking change so if it ever happens is likely to happen in a future major release. For now, the new maintainers are still finding their feet with the existing code base and taking over the weight from Matt, so expect more incremental changes in the short term.

@andrewtchilds One thing to consider is that there's also some applications that install per-user - installing via Administrator wouldn't work for that. It's something we'd also need to consider.

[andrewtchilds]

@flcdrg Good point. We disable the built-in administrator account on our workstations, so I don't think it'd work for most corporate-managed machines.

[ferventcoder]

Also added this so that folks are not in the dark when this occurs - nodejs/node#24000

[VinciShark]

@pauby Looks like it comes form Node.js
After install the newest Node.js, the script's shortcut comes into start menu.

[Degats]

Ignoring the fact that disabling UAC is in itself a monumentally terrible idea for security reasons, there are a few other issues:

1. If AD Group Policy enforces the use of UAC, this has the potential to cause an infinite reboot, as the computer UAC policy will most likely be applied before the user logs in to run the startup script (haven't actually tested this, but may be another cause of the reboot problems people have been having especially when on AD, see Node v11.0 windows installation opting into chocolatey+boxstarter results in infinite reboots nodejs/node#23838 ).

2. Following on from @andrewtchilds and @flcdrg if the user running the install does not have local admin privileges, the startup script will be installed in the profile of whatever account was used via UAC to elevate the install (assuming said profile exists, see later).
   This means that after reboot:

   • If the account with local admin rights has never been used to actually log on to the machine before, (very possible in an AD environment, especially as there is a GP setting that cleans up unused profiles after x days) the startup script may never have been installed as that account does not have a local profile
   • If the startup script was sucessfuly installed it will not actually run, as the profile it was installed to is not logged in.
   • It will be impossible to run anything elevated while a user without local admin privieges is logged in (because UAC is now disabled) until:
   • The account with local admin that was originally used to elevate the install must log in to the machine for the startup script to run and complete install/cleanup and reactivate UAC.
   • If the startup script was not installed because the local admin account's profile did not exist, another account with local admin privileges must log in to the machine to be able to manually re-enable UAC.

3. As a systems admin, I consider any installer that cannot be run completely silently for automated installs to be fundamentally broken. Errors should be able to be reported via log files and exit codes. Reboots should be able to be suppressed and done at the user's convenience later (quite frankly, the only thing that should even require a reboot before installation can complete is a firmware/driver update).

4. At least one of the reboots is forced. This prevents open programs prompting the user to save changes and therefore is likely to cause loss of work. I can think of no good reason for the reboot to be forced.