Symbolic links need protection?

It is not like I go read the WDK docs in my spare time, but one day I did and
I came across IoCreateUnprotectedSymbolicLink. Huh? An unprotected
symbolic link? I knew about IoCreateSymbolicLink
(which by induction would be a protected symlink), but I had never heard of
unprotected links. Reading the docs, it says:

    IoCreateUnprotectedSymbolicLink can be used by drivers if the user needs to be
    able to manipulate the symbolic link. For example, the parallel and serial
    drivers create unprotected symbolic links for LPTx and COMx, so that users can
    manipulate and reassign them by using the MODE command.

Well, that is not very helpful! I know that the serial driver does not create
symbolic links (you can look it up for yourself, it is a WDK sample), so I looked
at the implementation of the two APIs to see what was going on. What I found is that the difference between the two types of
links is the permissions associated with them. A link created by
IoCreateSymbolicLink has a fixed security descriptor
associated with the link itself, while a link created by IoCreateUnprotectedSymbolicLink
inherits its security descriptor from the \DosDevices container that it is
placed in. I would hazard a guess that you could use one of the NT object tree
browsers out there to confirm the ACLs for the different types of links.

What this means that you can now set the policy on all of the unprotected links
outside of the drivers that created the links. Only administrators can modify
protected links, while you could allow anyone to modify unprotected links. In addition
to the LPT ports being unprotected links, your network drivers are unprotected
links as well. This is what allows a non admin user to map and unmap drive letters
in his own sessions without requiring admin privileges.

Comments (0)