106

In linux every user can create symlinks, but in Windows I need an admin command line, or mklink fails. Why is that?

Improve this question
5
  • 1
    Indeed, why? Might be the references, by default enabled in programming languages like MS C#, is a vulnerability?!
    – Val
    Commented Mar 8, 2013 at 19:44
  • 14
    What's worse, hard links and directory junctions can be created by regular users AFAIK, just not symlinks. This restriction seems really arbitrary.
    – Ajedi32
    Commented Oct 30, 2015 at 15:44
  • 2
    See also: superuser.com/questions/10727/…
    – Ajedi32
    Commented Oct 30, 2015 at 15:44
  • 4
    A good answer should give an example how the SeCreateSymbolicLinkPrivilege can be exploited or abused. What is the risk involved? How does it soften security? Give a specific exploit example.
    – user643011
    Commented Jun 8, 2018 at 15:34
  • 3
    @user643011 , most likely some **** simply didn't implement permission check when application tries to access data by symlink. microsoft just can't hire competent developers for some reason.
    – Victor Yarema
    Commented Feb 13, 2020 at 12:04

5 Answers 5

Reset to default
36

By default, only administrators can create symbolic links, because they are the only ones who have the SeCreateSymbolicLinkPrivilege privilege found under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\ granted.

From Microsoft TechNet: Security Policy Settings New for Windows Vista:

Symbolic links (symlinks) can expose security vulnerabilities in applications that aren't designed to handle symbolic links.

Improve this answer
10
  • 7
    I'd love to read more details about these security vulnerabilities.
    – ripper234
    Commented Dec 29, 2011 at 10:51
  • 11
    @ripper234 Maybe something like this.
    – ordag
    Commented Dec 29, 2011 at 11:53
  • 35
    @Val Totally agree. The "SeCreateSymbolicLinkPrivilege" part explains HOW the rule is enforced, it doesn't explain WHY the rule exists in the first place. Now, the "security vulnerabilites" part does explain why admin rights were deemed necessary, and for me that's the only relevant part of this answer.
    – Pedro Rodrigues
    Commented Mar 12, 2014 at 17:21
  • 15
    From what I understand, Symlink Racing is a vulnerability that was patched at the kernel level in Linux some time ago: security.stackexchange.com/a/83977/29865 Is Windows still vulnerable? Is that why only admin users have this privilege? If so, why not just fix the problem instead of introducing stupid restrictions like this?
    – Ajedi32
    Commented Oct 30, 2015 at 15:34
  • 31
    Even the "Symbolic links ... can expose security vulnerabilities in applications that aren't designed to handle symbolic links." explanation isn't much of an answer. Examples? This is security.stackexchange.com, a Q&A site full of security experts, yet nobody can provide a concrete answer to this question? That seems telling.
    – jamesdlin
    Commented Jun 10, 2016 at 7:00
10

I found the reason when Vista was launched. The given reason for admins only is very simple. It's not unspecified security problems, it's thousands of pieces of software have to be upgraded to use API calls that literally didn't exist before they were added to avoid gaping security holes when traversing symbolic links.

Windows is horribly vulnerable to symbolic link racing; there are ways to avoid this, kind of, but virtually no applications are using the APIs in such a way at all. Even Microsoft is not accepting security bugs that involve symbolic link racing. I just tried to report one September 2018.

Update: During COVID we chose to patch one of our applications against symbolic link racing because some customer wanted to enable sideloading of "modern" applications (starting on Windows 10, unprivileged symbolic link creation is turned on by the same switch that enables sideloading). In going through one by one and fixing all the symbolic link races by total code audit we found that about one symbolic race in five was actually a junction race as well. Assuming we are typical, the reason is unreliable and most applications that would be vulnerable to symbolic link races were already vulnerable to junction races.

Improve this answer
4
  • Interesting. Any idea why Windows couldn't patch this at the kernel level like Linux did? (github.com/torvalds/linux/commit/…) Also, why aren't hardlinks vulnerable?
    – Ajedi32
    Commented Jan 3, 2019 at 14:22
  • @Ajedi32: Because Windows doesn't have a direct equivalent of root, and looking up group membership at path traversal time is stupid and the root of the drive is equivalent to stickty tmp
    – Joshua
    Commented Jan 3, 2019 at 14:53
  • 1
    @Ajedi32 Also, the Linux patch doesn't fully solve the problem, when dealing with sandboxes rather than fully different users. I found a TOCTOU bug in the broker process for a well-known program's sandbox where you could use a symlink (or junction, or hardlink) to break the broker process' assumptions about the sandboxed-ness of a file that the sandbox could "create", all without breaking the conditions in the Linux protection. This was an arbitrary write from within the sandbox via sandbox race. I've found similar issues in installers/updaters.
    – CBHacking
    Commented Oct 22, 2020 at 8:43
  • 2
    This should be the accepted answer, but it only made sense after I understood what a symlink race is. It would've required scanning and patching the entire universe of Windows apps, which is unfeasible, so it was better to keep symlinks off-limits and have the user confirm they really really wanted to create one.
    – Paul
    Commented Aug 18, 2023 at 6:35
9

It is not entirely (see below) the case anymore as of Windows 10 Insiders build 14972 (windows 10 creators update ~ 1703).

However, from the comments below the blog post, concerns about the issues mentioned in the other answers are still there, and to make use of this new behaviour, you need to:

  • enable developer mode on your machine
  • pass a SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag to the CreateSymbolicLink API
Improve this answer
1
  • 31
    Sigh. Once again, the blog post just cites unspecified "security requirements" as the reason for why this isn't enabled by default. Then when people question this in the comments, the author responds by again saying "they introduce very real security risks" and "There are some well documented security concerns with symlinks" without explaining what those risks are. This is ridiculous.
    – Ajedi32
    Commented May 9, 2018 at 15:19
7

Linux has a compartmentalised file/user structure. What that means is "program A" cannot do "task B" unless it's related to "disk space C". So symlinks don't really affect anything logistically in terms of risk penetration because the entire OS is predicated on the assumption of action->permission.

Or to put it another way, making a gazillion symlinks doesn't help you if you're a hacker with nothing but low-level permissions. So, on Linux or MacOS it doesn't help you.

However, on Windows you don't have a "program A" that runs a program other than the person logged in... so the person logged in can do "task B" to wherever they like. So it DEFINITELY helps you to have penetration to the level of symlinks because you can override commonly found real files with viral payload, and hide that you did it.

So, without the symlink protection level, a virus could infect you, run as its payload a lot of symlinks to, say, redirect "explorer.exe" to a fake "exactly-as-windows-made-it-except-with-a-payload explorer.exe".

Why would you do that? Quite honestly it's the keys to the kingdom. You could recruit that computer reliably into a bot theoretically activating its way into the future etc. There are a million ways why this is better than just "having an infection" because most people remove them when they see them, and this could be hidden.

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Commented Oct 24, 2020 at 11:56
1

Hardlinks and directory junctions are only inside one partition(there cant be a hardlink from one drive to another or even to a network location).

SymLinks on the other hand can also link from a place on the system which seems "safe" to a network location.

Improve this answer
7
  • 16
    And this is a problem because...?
    – jamesdlin
    Commented Nov 1, 2017 at 2:46
  • 3
    Directory Junctions (mklink /J) must be local, but they are allowed to point to another disk. You can mklink /J C:\mylink D:\mydir without problem.
    – Martin
    Commented Jan 22, 2020 at 12:54
  • 3
    Unix systems handle this just fine. Why is NTFS so arbitrarily crappy?
    – Ti Strga
    Commented Oct 21, 2020 at 22:49
  • @TiStrga Sort of OT, but what do you mean "handle this just fine"? You can't hardlink files on different volumes on any OS, that's contrary to the very concept of what a hardlink is. Symlinks between volumes work fine, on both NTFS and *nix filesystems. Junctions are a weird legacy in-between (they're not quite directory hardlinks but they're closer than symlinks, and mostly are just legacy from when NTFS didn't have true symlinks in the pre-Vista days).
    – CBHacking
    Commented Oct 22, 2020 at 8:35
  • 1
    @CBHacking yes, I know. I was referring to the supposed "danger" of creating a symlink to something that might be on a remote system which may or may not exist in the future. Windows freaks out, Unix just does it and gets out of the way.
    – Ti Strga
    Commented Oct 23, 2020 at 17:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .