Security: It's possible to debug elevated (UAC Win32 perms) WSL processes from non elevated ones.

[xilun]

Example:

1. Start an elevated bash.exe, check you can see admin only stuff e.g. ls /mnt/c/Windows/System32/sru
2. Start a second bash.exe, this time non-elevated, so be sad when ls /mnt/c/Windows/System32/sru yields "Permission denied".
3. From the non-elevated bash, gdb the elevated bash process.
4. It works! Hack the planet!
5. Profit :)

[fpqc]

Wow, great catch! I bet you could turn this into an exploit pretty easily!

[zhykzhykzhyk]

If both elevated user and restricted user are using the same linux user account, the attack may be trivial by using something like .bashrc, and almost unavoidable.

[zhykzhykzhyk]

I think root as elevated and #285 may be a good idea to solve the security issue although many one against it.

[fpqc]

@zhykzhykzhyk Well, maybe if they decide to do that, they can also make a proper sudo/elevate for powershell that doesn't require launching a new terminal window.

[xilun]

@zhykzhykzhyk you're right, I did not think about that. There are probably many way to use an elevated bash to perform uac bypass, and the only sane way to close all the hole seems to be more mapping between Wsl and regular Win security. However simply mapping root to admin is problematic because of the usage model: non-admin users would not be able to administer their wsl instance.

So I guess running bash as elevated should always be considering as a risk of allowing UAC bypass, and the users should be at least warned about that.

[xilun]

Maybe a mitigation would be to only allow effective usage of the admin right, if present, by root. This way with a strong enough password, this seems to restore more security (probably not perfect). This is a little complicated, though.

[stehufntdev]

Thanks for reporting the issue! We will take a look.

[benhillis]

We have resolved this in recent Insider builds by only allowing processes of one NT integrity level in WSL instances.