Linux versus Windows. It's a battle that is raged through internet forums, spawning many a flame war. In recent years, though; Microsoft have put down the hatchet, and started to embrace open source. That has resulted in the birth of something that many of us never expected to see - the Microsoft Linux kernel, and the ability to run Linux in Windows 10.
Some of you are no doubt wondering "What is he talking about? How can Windows run Linux? They're completely different operating systems!". I hear what you're saying, but take a look at this... This is the Windows command prompt. It's not the shiny new Windows Terminal. It's the old boring prompt we're all used to. Not a lot to see here. I can run DIR to see the contents of the current directory, but i can't run LS of course because this isn't Linux. And yes... I know PowerShell can; but that's just because both DIR and LS in PowerShell are aliases for the Get-ChildItem cmdlet. That doesn't work in the bog-standard Windows prompt, as you can see; but what if i type
wsl ls i'll explain what WSL is later. That actually did something. Let me put a "-L" on it. That's starting to look rather Linuxy. Here's another staple Windows command: "CD" for the "Current Directory". Yeah, OK, we're in "C:\Program Files\ Microsoft Office". That's definitely Windows. The equivalent Linux command would be "PWD" for "Print Working Directory". Obviously, that doesn't work; but what about "WSL PWD"? Not only does that work... look at the path! No Windows path starts with a forward- slash. That's a Linux path, showing our Windows "C" drive mounted as "
/mnt/c". OK, sanity check. What are we running, here? That's Windows 10 Pro - definitely not Linux. So what is this WSL thing doing? Let's try the "WSL" command by itself. Now that... that's Bash. That's more like a Linux terminal, and here's what happens if you run "
ls -l" now. Not only does it work... we've even got the colours! Let's check our system info again. That doesn't work because, that was a Windows command and "Toto, I have a feeling we're not in Kansas anymore".
So is this Linux? If this were Linux I could find out what distribution we're running by looking at "
/etc/os-release". Now, that is not Windows. That says Ubuntu Linux! But I've not configured the WSL command as some kind of shortcut to SSH onto a Linux box that I just forgot to tell you about. Let's look a little deeper and check what kernel we're running. You are reading that correctly. That is a Microsoft Linux kernel. Imagine trying to explain that to someone back in the Ballmer days. I
So what are we looking at, here? This is the Windows Subsystem for Linux, which i'm going to abbreviate to WSL. There are actually two versions of this. Windows will default to using WSL1, but if you're running the 2004 version of Windows 10 or later, you might want to switch to WSL 2. WSLs 1 and 2 work in very different ways, so it's worth explaining both of them. WSL1 is essentially a compatibility layer. It pretends to be a Linux kernel to the application, but it's taking Linux calls from Linux applications then converting those in the fly to the equivalent Windows calls; before passing them back to the standard Windows kernel. Then it converts the response back from Windows to Linux on the return trip. This gives you a way to run native Linux applications on Windows.
WSL2 works quite differently. Rather than pretending to be a Linux kernel, WSL2 uses virtualisation technology to host an actual Linux kernel, inside a virtual machine. This means it's actual, proper Linux. This approach is a lot more efficient, because you're not having to translate everything from Linux to Windows, and back to Linux again. That means WSL2 has better performance and better compatibility, compared to 1. This difference in approach is also why the name "Windows Subsystem for Linux" feels a little bit back to front. It almost makes more sense to think of it as the "Linux Subsystem for Windows", but as i understand it, Microsoft weren't allowed to start a product name with the Linux trademark unless it used an actual Linux kernel; which WSL1 didn't.
Although WSL2 is using some of the same technology as Hyper-V; you won't see a virtual machine in Hyper-V, and you can't log on to a console anywhere in the usual sense. It's a highly optimised virtual machine, with low overhead and fast startup. It's also tightly integrated with the running Windows host. A normal virtual machine is isolated from the host. With WSL, Linux and Windows can talk to each other and share information with each other - blurring the lines between the two systems.
You can also type "
\\WSL$" in Windows to get to the Linux filesystem. Let's do something a little more visual. If this is Ubuntu, I can install Webmin, right?
If I was running Linux, I could open a browser and go to localhost; but because i'm running Windows, localhost refers to my Windows computer... or does it? WSL is clever enough to know that port 10000 has just been grabbed by Webmin in Linux, and it automatically redirects that through from Windows. So i can just browse to localhost on Windows, and reach Webmin as if it was running natively on Windows. Now we've got something visual, I'll just click through the filesystem to show you can indeed access Windows files from Linux; including the live "System32" directory, if you really wanted to.
That's pretty cool. Could we push it a little further and deploy something like Nextcloud? Yes; and i did. "http://localhost/nextcloud" and there we go. That's Nextcloud, running on Apache, on Ubuntu, on the Microsoft Linux kernel, on Windows.
The ability to run Linux natively in Windows is really interesting... but what exactly is the point of this? Am I suggesting that Windows admins who find themselves needing to deploy Linux services should deploy those in Windows using WSL? No. Just build yourself a Linux server. There's no sense in over-complicating it, or limiting yourself like that. If you need Linux in production, deploy Linux; not Linux on Windows. So what is this for?
Well you could use it for a few things, really, and I've got an interesting one to show you later; but the explicit reason Microsoft created WSL was for developers. A lot of developers use Windows; but just because the developer works in Windows, and develops in Windows, doesn't mean the application they're writing is going to run on Windows. Let's say you're developing an app for Nextcloud. You might want to develop it in Visual Studio on Windows, but you're going to deploy it to run on Linux. In that case, the ability to run Linux locally on Windows for testing and debugging would be a great time-saver.
The same argument goes for cloud development. The fact is that most developers are running Windows, and most cloud services are not. You can make arguments all day long about which operating system is better, but if you're deploying to the cloud and you've outsourced all of the operating system management to the vendor then most of these arguments are irrelevant. What it really comes down to is this: do you need a specific runtime or integration that only works on a specific platform? If not, and someone else is managing it for you... well what you're left with is Linux is usually the cheaper subscription option. So that's the reason the Windows subsystem for Linux exists; but it's not the only reason to use it. It might be an easy way to start dipping your toe in if you want to give Linux a try; although, honestly, I'd recommend installing it as a full virtual machine. You'll learn a lot more if you start from the beginning, and there are weird little gotchas with WSL if you try to treat it like a standalone server. Like rebooting. I've not really found any way to reboot the underlying virtual machine, other than shutting down WSL.
An interesting use case I've stumbled across, though, could be for penetration testing. You've seen me running Ubuntu; but that's just one example. WSL uses the Microsoft Linux kernel, but you can install different distributions on top of that. Funny enough, you install your Linux distributions from the Microsoft store. Who'd have thought that was coming? We've got a few options there, including SUSE and Debian, but this isn't the full list, either. Watch this. That's fedora. Fedora that you pay for, mind. My brain isn't quite sure how to process that yet. In fairness, that Fedora distribution is not endorsed by the Fedora Project or Red Hat. It's a third-party remix. The third party has put in a lot of effort to pack up the Fedora derivative and make sure it plays nicely with Windows, so it's fair that they could expect to be compensated for it. It's just that paying for Fedora feels almost as weird as running Linux in Windows. But anyway. That Fedora remix isn't what i wanted to show you.
What i wanted to talk to you about was Kali. If you're not familiar with Kali; it's a Linux distribution filled with all manner of security tools. The kind that can be really useful to a security researcher; or can land you in prison, depending on what you do with them. The really interesting thing about Kali and WSL, is that they've come up with a way to give you access to the desktop experience. The reason you've only seen me use the command line or a web interface so far, is that WSL does not support a traditional graphical interface. There's no actual console you can log on to. That's not as much of a limitation as it might seem, because most Linux systems are configured to only provide a command interface anyway.
Running a desktop on a server is often considered to be bad practice. But watch this as a load up Kali... and if i run
kex I'm now in the full Kali desktop ,in Windows. There is a bit of cheating going on here. This isn't running natively. If I hit F8 you can see what's really happening. This actually loaded a TigerVNC client in Windows, and used it to remote onto the desktop of the WSL machine running Kali. But I have to say, it seems to work quite well. Now, full disclosure - I've not done much with this other than load it up, go "ooh", and open a few apps; and i don't know if there's any gotchas to be aware of; but i do know a lot of pentesters use Kali to run their tests, and then go back to Windows to write up their reports. Being able to run both from within Windows, and have easy access to any testing exports from Linux in Windows seems like it could be a handy time-saver.
What about you? Have you found any interesting uses for the Windows Subsystem for Linux? Comment below, and upvote your favorites. I'm really interested to see what you guys come up with.