Microsoft Explains More About Their Windows Subsystem For Linux

[jrch2k8]

Android is absolutely more secure than most any ootb distro.
You can also infiltrate Linux remotely, and if you're local, the grsec guy has a few videos up showing how to get around selinux (I doubt most of them still work, but I'd also get he's aware of other exploitable code).
Linux really needs to move towards doing root altogether. I know this is just a massive pain but seccomp2 is truly useful (despite what Mozilla thinks). Capsicum is what we really need, though. That should allow us a path to simply getting rid of root (which seems, to me, to be the direction at least some Linux distros are heading).

1.) Android security(specially at runtime) is not great from my experience(may have improved since the first 5 release tho), you can google it, is specially weak against injections and crappy apps that allows it(to be fair all JIT runtimes suffer from this in some form or the other)

2.) in 2.4 was true, today a proper hardened setting make it extremely challenging, unless of course your network facing service have a specific vulnerability and it can scale privileges or is SUID(CGroups2 can fix this with systemd be it nspawn isolation or simply cgroups magic if your kernel is recent enough, ofc selinux, acls can too). As always IPtables is your tough jacked friend.

3.) i love grsecurity very badass team

4.) systemd process isolation and container system partially fix this issue, since no root is the actual root outside systemd but the root on that namespace/PID, so far i haven't been able to escape nspawn or find any possible attack on it, same holds true on systemd process isolation(even parallel forking of hand crafted stack overrun/SIGXXXX code can't leave the parent process and scale privileges attaching to PID1(or any other PID for that matter) like all other inits allow). I'm sure someone will find a way but goddamn is tough as it is

5.) the systemd way is half way there(it does seccomp btw), the only step left is to remove the real root(or leave it as PID1 exclusive) and let systemd provide pseudo isolated roots users per PID. that should remove some impact to the user and allow old apps to still work but safer. This would require distros to preset some seccomp validation filter per service(selinux profiles would nice too) tho.

As a side note, removing fully the root users is not a magic pill, sure it will help again kiddie/mid grade attacks but hardcode privilege scalation attacks don't actually need root as an user to be present just a vulnerable page/context or PID to work some dark magic and not always you require a full attack to the O.S(in fact is rare) but scale or switch privileges enough to attach to an specific target(like lets say an Oracle DB that doesn't run as root to start with) since the hackers that have the skills to do this are often after money after all

[unixfan2001]

Immune?? no but is extremely hard to achieve compared to how damn easy is on windows(in fact you can take control of a Win10 system with less than 50 .NET LoCs and that is overkill compared to attacking remotely Edge or IE).

Android is a completely different case since it makes no sense to attack linux when you can easily spoof the VM and since ARM is a clusterfuck where basically every phone have a completely different kernel version/build is even more annoying(note android disable lots of security features too that can be annoying to the final users).

So, in resume yes it is possible to compromise linux but it can get really hard and most of the time is very dependant on the target system kernel/distro/compiler/application specific versions and even when you succeed is not easy to mass apply it either or take down the entire OS the way is possible on Windows.

so what you are saying is, rob a bank should easy because my "secure little wood box" can be opened too and i heard people rob banks, sure but that doesn't mean the level of expertise and effort are nearly the same, that why people put jewels on banks and not under the bed in a wood box

google this stuff you will be amazed, is really interesting

Hogwash!

The claim that GNU/Linux is inherently more secure than other OS' is, quite frankly, a giant fallacy and probably the no 1 security threat to the whole plattform.
There are many straightforward ways to target a GNU/Linux box, as there are many quite outdated and vulnerable technologies under the hood.

Just take X11 for one. Or the issue with the EFI variables (where it would only take one line of bash VS a few lines of .NET). Or Heartbleed.
All these things are testament to the quality problems within the developer community.

Considering GNU/Linux inherently secure by default will almost certainly lead to insecurity.

[jacob]

Does WSL support 32 bit binaries, 64 bit, or both?

[ssokolow]

Hogwash!

The claim that GNU/Linux is inherently more secure than other OS' is, quite frankly, a giant fallacy and probably the no 1 security threat to the whole plattform.
There are many straightforward ways to target a GNU/Linux box, as there are many quite outdated and vulnerable technologies under the hood.

True, but at least it has many more PEBKAC mitigations than Windows does. For example:

• It's feasible for users to be taught to only look outside the package manager in extreme circumstances and KDE has a package manager for desktop theming resources too.
• There's a unified system for pushing out application security updates
• There's no legacy reason for users to get used to clicking through UAC dialogs without thought
• Files like CatPicture.jpg.exe can't have custom embedded icons and extensions aren't hidden
• Files must be manually marked executable
• Media players ignore "Go here to apply for DRM authentication" URLs in things like ASF files
• Nautilus is popular and asks for clarification on what you meant to run if a file's extension and header don't match
• It tends to be less of a monoculture at the application level, which reduces the chances of an exploit applying successfully

[ormaaj]

The Windows Subsystem for Linux is interesting technology but bound to be plagued by the same problems that Wine has--namely that not all apps will work on it

Wine has a much more difficult job. Wine is responsible for implementing both an abstraction for the NT kernel plus the win32 system libraries and all other userland subsystems and components that win32 applications depend upon. Providing that fully-compatible library-level implementation is phenomenally more complicated.

The architecture of Linux being what it is allows Microsoft and other OSes to take a huge shortcut. The entire userland including the C library (which includes the critically-important system call interface) can just be directly borrowed and dropped in as-is. There's relatively little to re-implement outside of the system-call interface exposed by the kernel to the C library, which in turn provides the application-level interface to the rest of the system for free.

[gotwig]

I wonder what the current status of the Linux Unified Kernel is? That project tried to implement Windows system calls and driver model into the Linux kernel and ran Win PE binaries.

https://en.wikipedia.org/wiki/Longene

The Windows Subsystem for Linux is interesting technology but bound to be plagued by the same problems that Wine has--namely that not all apps will work on it, especially those that require compiled kernel modules.

I had a chance to try out Bash on Windows the other day. I made a video briefly testing WSL along with some other apps and games a few days ago:

Can you pls share the scripts ? Im curios

[jrch2k8]

Hogwash!

The claim that GNU/Linux is inherently more secure than other OS' is, quite frankly, a giant fallacy and probably the no 1 security threat to the whole plattform.
There are many straightforward ways to target a GNU/Linux box, as there are many quite outdated and vulnerable technologies under the hood.

Just take X11 for one. Or the issue with the EFI variables (where it would only take one line of bash VS a few lines of .NET). Or Heartbleed.
All these things are testament to the quality problems within the developer community.

Considering GNU/Linux inherently secure by default will almost certainly lead to insecurity.

Again random half truth nitpicking to make a certain random point look valid. oughh ok lets go again

X11: true that is why wayland is coming but the other half thruth is that is easily mitigated just by running it without root priv(i think Arch and fedora do it already). Input redirection is still possible to attack tho but can be avoid using wayland and Xwayland togheter for now.

EFI: sure is true, the other half truth it affects windows and any other O.S that process EFI variables. Additionally depending how crappy is your motherboard UEFI BIOS this attack can be used to compromise the PXE rom too and infect other PCs when using related tools.

Heartbleed: True this was a big clusterfuck, the other half truth it affected Windows/Mac/BSD/etc too, Why? because OpenSSL is an extremely popular multiplatform userspace project unrelated to linux development or security model. In all affected cases this security fail didn't actually affect the underlying O.S but the actual encryption/decryption KEYS inside OpenSSL and was a big deal because every HTTPS service on the internet probably uses OpenSSL to validate certificates and encrypt.

Consider any O.S secure by default is idiocy, i Agree.
No O.S is 100% secure, I agree

Again the point is context, sure a jewel box and a bank vault can be considered secure in certain scenarios and both can be violated/attacked but again the kind of skill required to attack each is vastly different.

UNIX like Kernels are inherently more secure(not 100% secure, remember context!!!) than NT based kernels due how the kernel administrate and deal with resources, this is factual, this has been proved by expert 100 thousand times but that doesn't mean is all automatic or that it will fix every possible security scenario for you(to start with the word Security can mean 600 different crap in computer science) or that you don't need knowledge or study to ensure safety.

What more secure means? it simply means that with the right level of security knownledge and the proper tools Unix like Kernels can provide some extra resistance layer to attacks compared under similar conditions to an NT based kernel.(there are extensive technical papers that can explain this on grimm technical detail) thats it, no magic or witchcraft or human sacrifices to the bits gods

[duby229]

What is WSL?

Edit: Nevermind ( Windows Subsystem for Linux)

How did you run Windows 10 like that?

I'm pretty sure he is running Arch linux in that video.

[Tomin]

UNIX like Kernels are inherently more secure(not 100% secure, remember context!!!) than NT based kernels due how the kernel administrate and deal with resources, this is factual, this has been proved by expert 100 thousand times but that doesn't mean is all automatic or that it will fix every possible security scenario for you(to start with the word Security can mean 600 different crap in computer science) or that you don't need knowledge or study to ensure safety.

This is interesting. Does this mean that Microsoft can't make Windows (well, NT kernel) as secure as Unix kernels are (at least not without breaking user space)? Or is it just very hard and not worth it? I suppose this is a problem for other NT kernels as well (ReactOS comes to my mind, I'm not aware of any other NT kernels than it and Microsoft's).

[GabrielYYZ]

So, do we consider this the "extend" phase or are we still on the "embrace" phase? I guess it'll be 2-4 years until the "extinguish" phase.