5

This questions is a followup to Why is SeCreateSymbolicLinkPrivilege ignored on Windows 8?

Given:

  1. The user is in the Administrators group
  2. Turning off UAC is not an option for me.
  3. Running elevated is not an option.

Question: Is it possible to add the SeCreateSymbolicLinkPrivilege to the Standard User Token created by Windows for an admin user?

Appendix

Non elevated admin user:

C:\dayforce\SharpTop>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                          State
============================= ==================================== ========
SeShutdownPrivilege           Shut down the system                 Disabled
SeChangeNotifyPrivilege       Bypass traverse checking             Enabled
SeUndockPrivilege             Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set       Disabled
SeTimeZonePrivilege           Change the time zone                 Disabled

C:\dayforce\SharpTop>

A regular user:

C:\Windows\system32>whoami /priv

PRIVILEGES INFORMATION
----------------------

Privilege Name                Description                          State
============================= ==================================== ========
SeShutdownPrivilege           Shut down the system                 Disabled
SeChangeNotifyPrivilege       Bypass traverse checking             Enabled
SeUndockPrivilege             Remove computer from docking station Disabled
SeIncreaseWorkingSetPrivilege Increase a process working set       Disabled
SeTimeZonePrivilege           Change the time zone                 Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links                Disabled

C:\Windows\system32>

Notice a regular user has the SeCreateSymbolicLinkPrivilege privilege, because I have enabled it in the Security Policy. But the admin user is screwed, because doing so does not affect its Standard User Token!

Community
  • 1
  • 1
mark
  • 59,016
  • 79
  • 296
  • 580
  • No, there is no (reasonable) way of doing this. (Of course, you could write a service that creates symbolic links on your behalf.) – Harry Johnston Apr 30 '15 at 04:34
  • I don't know if there's any way to customize the elevation split-token scheme, but you could elevate and then call `CreateRestrictedToken` to make a custom sandbox. – Eryk Sun Apr 30 '15 at 17:13
  • Doing so would contradict the requirement 3 - _Running elevated is not an option_ . This also means running elevated even for a brief moment. The reason - elevation requires user interaction. – mark Apr 30 '15 at 17:32
  • How about using a service to create the restricted token? From a service you can get the linked administrator token of the console user, and then create a new process in her session with a restricted token. – Eryk Sun May 01 '15 at 16:26
  • That could be a solution, but it means deploying an additional component, even if it is a one-time deployment. It is doable, but much more complicated, because instead of a simple command line we now have to communicate with another process. Still, arrange as an answer and I will up-vote it – mark May 01 '15 at 17:50
  • There is no known way in Windows to add privileges to an existing token. Privileges can be enabled, disabled, and removed but not added. That said, you could *create* a new token from scratch that has the privilege you want. Here's a tool that can be used to start a child process with SeCreateSymbolicLinkPrivilege as part of its primary token: https://github.com/cubiclesoft/createprocess-windows It requires temporary elevation though. This seems like a bug in the OS. If every member of BUILTIN\Users is supposed to get a certain privilege, then LSASS should not ignore that for admins. – CubicleSoft Dec 10 '21 at 14:50

1 Answers1

2

(this is a nonanswer to the actually-asked question, but it is an attempt at an answer for what I perceive to be the actual goal)

I feel your pain -- I've been looking for a way to permit an admin user running nonelevated to create Symbolic Links, without success ...

  • I've investigated altering the process token (of "explorer" perhaps) to add the SeCreateSymbolicLinkPrivilege privilege, but it appears that there is no way to alter the privilege set of an existing token. Even if your patch process runs as SYSTEM and/or has the SeTcbPrivilege privilege.

  • I've investigated using CreateRestrictedToken to create your "own" nonelevated process, but with the SeCreateSymbolicLinkPrivilege privilege left enabled. But all anecdotes I've read about CreateRestrictedToken suggests that the resulting token cannot be made sufficiently similar to an "authentic" nonelevated token. There were insurmountable issues with the integrity level, or with the elevated flag associated with the token.

  • No matter what users you assign to the create-symlink user right in security policy manager, if your process runs nonelevated (from a user with admin), the SeCreateSymbolicLinkPrivilege privilege gets removed. This happens even if the only user added is "Everyone".

Microsoft really fouled us up on this one, there appears to be no good workaround. There is a possibly hackish solution though ...

Now for the hackish solution - during logon of the user, start a background program (elevated) which will create symlinks on behalf of other processes. This will need to use some sort of IPC, perhaps named pipes, to receive create-symlink-requests from the client process. It's ugly, and probably slow, but other than running Elevated (or disabling UAC), or removing the user from the Administrators group, I don't see any other way.

William
  • 690
  • 5
  • 13
  • See the comment by eryksun - he has suggested essentially the same - create service running under a regular account that would create symlinks on behalf of the non elevated admin user. – mark Apr 23 '16 at 02:27