Docker 3.6.0 installation failure due to 'SeSecurityPrivilege' privilege

[georgebv]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
  • not applicable
• I have uploaded Diagnostics
  • Diagnostics ID:
    • not applicable

Actual behavior

Docker desktop fails during installation

Expected behavior

Docker desktop gets installed successfully

Information

• Windows Version: 20H2 (OS Build 19042.1165)
• Docker Desktop Version: 3.6.0
• WSL2 or Hyper-V backend? Both are enabled
• Are you running inside a virtualized Windows e.g. on a cloud server or a VM: No

These are the logs I am getting

[16:23:56.577][Installer         ][Info   ] Deleting directory C:\Program Files\Docker\cli-plugins
[16:23:56.585][Installer         ][Error  ] The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.
[16:23:56.609][InstallWorkflow] Installation failed
Exception type: System.Exception, Exception message: Component CommunityInstaller.ExecAction failed: Process InstallerCli.exe exited with code 1, StackTrace:
   at CommunityInstaller.InstallWorkflow.<DoHandleD4WPackageAsync>d__29.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at CommunityInstaller.InstallWorkflow.<DoProcessAsync>d__23.MoveNext()
[16:23:56.612][InstallWorkflow] Rollbacking component CommunityInstaller.PathAction

This is not an issue on Docker Desktop 3.5.2 or earlier, so it has to be 3.6.0 issue.

This issue also happens when updating Docker Desktop via the app itself - it fails during the update and, instead of rolling back the changes, it simply uninstalls Docker completely.

Steps to reproduce the behavior

1. Run the Docker Desktop 3.6.0 Installer

[bartMarinissen]

I can confirm I just had the same issue with installing 3.6.0. Managed to resolve the issue by installing an earlier version of Docker. (I picked 3.2.0)

Edit: whilst installing an older version works, the older version automatically wants to update itself again, which causes the update to fail and leaves me without a functioning docker install.

[AllanMedeiros]

I'm facing this issue too. The auto update to 3.6 failed, then I downloaded 4.0 and also failed to install, so I have to go back to 3.5.2.

[hmunikar]

I am having the same issue of installation failed due to 'SeSecurityPrivilege' with 4.0.0. I was successful in installing 3.5.2. Logfile attached.
install-log.8.txt

[schubertrod]

Same here, this privilege provides access to "Manage auditing and security log", and would be blocked on most enterprise machines through group policy, so even as an Admin we'd not be able to set it. Probably needs a way to bypass or make this check optional

More details: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/manage-auditing-and-security-log

Note: 3.5.2 seems to be the last version working, issue persists on version/4.0.0 as well

[DecisionSystems]

Having the exact same experience described above. Having to re-install 3.5.2 I'm guessing these installs blow away everything too forcing re-install of all K8 components, VS Code add-ins and linux distro. We shall see :-(

[djs55]

Thanks for the report.
The installer is trying to create the directory %PROGRAMDATA%\Docker (e.g. C:\ProgramData\Docker). The permissions are normally too permissive, so they need to be restricted. Possibly it's trying to remove too many of the ACL rules.

Could you create a directory (from powershell)

mkdir C:\ProgramData\Docker

and then view the ACLs with:

Get-ACL C:\ProgramData\Docker |% access

Thanks!

[bartMarinissen]

When I ran mkdir C:\ProgramData\Docker the folder already exists.

The ACL output is:

PS C:\WINDOWS\system32> Get-Acl C:\ProgramData\Docker |% access

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited       : True
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited       : True
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : 268435456
AccessControlType : Allow
IdentityReference : CREATOR OWNER
IsInherited       : True
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : InheritOnly

FileSystemRights  : ReadAndExecute, Synchronize
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited       : True
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : Write
AccessControlType : Allow
IdentityReference : BUILTIN\Users
IsInherited       : True
InheritanceFlags  : ContainerInherit
PropagationFlags  : None

I do find it confusing that this has anything to do with the windows event log. But maybe I just don't understand how windows works.

[schubertrod]

FYI, I had mentioned above, these rights have nothing to do with file/folder permissions, the docker inslaller is looking for privilege to manage the security and audit logs of the Win OS, which is maintained/set by local/group policy

[djs55]

@bartMarinissen thanks for the command output. The installer is trying to set the ACLs to a minimal set:

PS C:\WINDOWS\system32> Get-Acl C:\ProgramData\Docker |% access


FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

The installer is trying to delete rules which grant access to BUILTIN\Users in case they make the system vulnerable to CVE-2021-37841, where members of BUILTIN\Users can escape from a Windows container to the host. Obviously this is only an issue if you use Windows containers and if members of BUILTIN\Users are not supposed to have local Administrator access in the first place.

I'm not sure whether

• the local/group policy is now enforcing an insecure configuration, so the local/group policy should be changed (/cc @schubertrod )
• or perhaps the failure to change permissions should be a non-fatal error and we should block the Windows daemon startup instead?
• it's possible to remove the inherited rules through another API which doesn't trigger the permission error.

What do you think?

[georgebv]

@djs55 I have the same logs as @bartMarinissen . But I believe that @schubertrod is correct - I run Docker on my company laptops and, starting version 3.6.0, no one in my organization can install Docker. I asked our IT and they agreed this is an issue as many use Docker in our organization, but they said that under no circumstances would they grant SeSecurityPrivilege to 3rd party processes. Why does Docker suddenly need this permission? There has to be a way, older versions still work.

[djs55]

@georgebv regarding

Why does Docker suddenly need this permission? There has to be a way, older versions still work.

See the comment above -- if the permissions on C:\ProgramData\Docker are incorrect then it's possible for a user with Admin in a Windows (not Linux) container to escape to Admin on the host. Older versions of Docker are vulnerable to this CVE; versions 3.6.0 and later are immune. If you run an old version of Docker (before 3.6.0) and Windows containers and your IT security policy prevents developers having Admin on their machines, then the IT policy can be bypassed.

As an experiment, see if you can figure out how to remove the ACLs from C:\ProgramData\Docker for everyone except NT AUTHORITY\SYSTEM and BUILTIN\Administrators through either powershell or Windows explorer and post the results of Get-Acl C:\ProgramData\Docker |% access. I'm not sure whether it's impossible to achieve this with the current security policy (if so, perhaps we should block the Windows engine rather than the whole installation) or whether it's the API we're currently using in the installer.

Thanks for your help investigating this!

[schubertrod]

@djs55 I've had to manually disable permission inheritance on the C:\ProgramData\Docker folder, n then I configured the permissions (see below results from powershell), I'll try to see if the latest version/4.0.1 works next...

PS C:\WINDOWS\system32> Get-Acl C:\ProgramData\Docker |% access                                                         

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : NT AUTHORITY\SYSTEM
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

FileSystemRights  : FullControl
AccessControlType : Allow
IdentityReference : BUILTIN\Administrators
IsInherited       : False
InheritanceFlags  : ContainerInherit, ObjectInherit
PropagationFlags  : None

[schubertrod]

@djs55 No dice, it didn't work and still threw a SeSecurityPrivilege error. Not sure what the installation is doing, but I think it's using set-acl.
Based on something I see here, it may work if the installation uses SetAccessControl() instead

[djs55]

@schubertrod thanks for the link. The current code is calling SetAccessControl but with a descriptor created from an SDDL string (intended to match the one in https://github.com/moby/moby) . I've changed the code to be more similar to the example from that link. It now:

• SetAccessRuleProtection(true, true), then SetAccessControl. This is to avoid inheriting changes.
• filters the rules and removes the unwanted ones, calls SetAccessControl.

I've also added more logging so we should see which of those steps fails (if it fails). If you have time to test it there's a test build here: https://desktop-stage.docker.com/win/main/amd64/68607/Docker%20Desktop%20Installer.exe

Thanks!