search

rdp / os

The OS gem allows for some easy telling if you’re on windows or not. OS.windows? as well as some other helper utilities
MIT License
145 stars 33 forks source link

Added checks for Windows Subsystem for Linux on Windows 10 #33

Open mccarrmb opened 6 years ago

mccarrmb commented 6 years ago

The new Windows Subsystem for Linux allows guest Linux OS's to seamlessly masquerade as an actual Linux host. However, these guests have the ability to run both Windows and Linux binaries - necessitating a need to determine if the underlying OS is actually Windows-based.

This code has been tested in MinGW32, CygWin, macOS, Ubuntu, Ubuntu on WSL, Kali on WSL, and Windows 10.

rdp commented 5 years ago

I've mulled on this one a bit...it's tricky because it's like is OS the runtime or actual OS...maybe if I add a "underLying" class or what not...

On Fri, Aug 3, 2018 at 9:45 AM Whitey notifications@github.com wrote:

The new Windows Subsystem for Linux allows guest Linux OS's to seamlessly masquerade as an actual Linux host. However, these guests have the ability to run both Windows and Linux binaries - necessitating a need to determine if the underlying OS is actually Windows-based.

This code has been tested in MinGW32, CygWin, macOS, Ubuntu, Ubuntu on WSL, Kali on WSL, and Windows 10.

You can view, comment on, or merge this pull request online at:

https://github.com/rdp/os/pull/33 Commit Summary

  • added new underlying check
  • Merge remote-tracking branch 'upstream/master'

File Changes

Patch Links:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rdp/os/pull/33, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0JWMlvy5V_EgmFzHNWeTfwG6wKFMks5uNHAlgaJpZM4VuN_h .

mccarrmb commented 5 years ago

Yeah this is an odd one because of how WSL works. Normally, Cygwin executables either have hooks for the Cygwin DLL or they're compiled from source under the Cygwn environment. This means that there is an environment limitation that would be helpful for Ruby to be aware of. WSL, however, is like a seamless super-set of both native Linux and Windows NT executable types.

Normally, I would have left the existing behavior as-is since it wasn't really wrong to determine that the environment was Linux. Unfortunately, I'm using these changes to identify a special edge case for browser automation. These changes allow me to use a sane implementation of Ruby while enabling the ability to detect the existence of Microsoft web browser resources.

rdp commented 5 years ago

maybe a new method hmm

On Mon, Oct 15, 2018 at 7:30 AM Whitey notifications@github.com wrote:

Yeah this is an odd one because of how WSL works. Normally, Cygwin executables either have hooks for the Cygwin DLL or they're compiled from source under the Cygwn environment. This means that there is an environment limitation that would be helpful for Ruby to be aware of. WSL, however, is like a seamless super-set of both native Linux and Windows NT executable types.

Normally, I would have left the existing behavior as-is since it wasn't really wrong to determine that the environment was Linux. Unfortunately, I'm using these changes to identify a special edge case for browser automation. These changes allow me to use a sane implementation of Ruby while enabling the ability to detect the existence of Microsoft web browser resources.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rdp/os/pull/33#issuecomment-429853115, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0DlmPcfVn1ymWtcqGj-mKN0Ar5SRks5ulI4OgaJpZM4VuN_h .

mccarrmb commented 5 years ago

Maybe a method that detects the type of binary formats that can be executed in the current environment?

rdp commented 5 years ago

I like that...

On Wednesday, October 17, 2018, Whitey notifications@github.com wrote:

Maybe a method that detects the type of binary formats that can be executed in the current environment?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.< https://ci4.googleusercontent.com/proxy/T4FmcLZoxoNQ39Wk0VpOrgXt55KSCGKxEgA6ZA_E2aPMQy6slgeK1Yf1xxbPLPLyKHBVj3K4tMt1-yVQYSLekEIJ5r5VECGAcFBVe4FxwrKXqiBIXcdWS9qNATcJY3eggADRef4wN_ZT7giMyEiov86ZOHaCJw=s0-d-e1-ft#https://github.com/notifications/beacon/AAAw0JBq_a4MAlNQK-mAzWcuVcURW3Srks5ul1NcgaJpZM4VuN_h.gif>

mccarrmb commented 5 years ago

I've been thinking about this for a while and have since looked to the official documentation to see how these types of environments determine whether Windows PE executables can be run. According to the Interoperability Documentation, the key determining factor is provided by the /proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to enabled. In fact, setting this to a "disabled" state will prevent any Windows PE code from running in the subsystem at all.

Would it be acceptable to modify this submission to key off of this WSL interop process? My intent with this change would be to determine whether Windows executable resources would be available within an environment that appeared to be Linux-based.

rdp commented 5 years ago

I like your idea of a new method "windows exe's can run" or what not...wait should that include wine? maybe just cygwin and wsl for now? :)

On Tue, Mar 19, 2019 at 3:44 PM Whitey notifications@github.com wrote:

I've been thinking about this for a while and have since looked to the official documentation to see how these types of environments determine whether Windows PE executables can be run. According to the Interoperability Documentation https://docs.microsoft.com/en-us/windows/wsl/interop, the key determining factor is provided by the /proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to enabled. In fact, setting this to a "disabled" state will prevent any Windows PE code from running in the subsystem at all.

Would it be acceptable to modify this submission to key off of this WSL interop process?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rdp/os/pull/33#issuecomment-474596539, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0JWt71FMTScd4gDglq2QB_ye-rErks5vYVojgaJpZM4VuN_h .

mccarrmb commented 5 years ago

I like your idea of a new method "windows exe's can run" or what not...wait should that include wine? maybe just cygwin and wsl for now? :) … On Tue, Mar 19, 2019 at 3:44 PM Whitey @.***> wrote: I've been thinking about this for a while and have since looked to the official documentation to see how these types of environments determine whether Windows PE executables can be run. According to the Interoperability Documentation https://docs.microsoft.com/en-us/windows/wsl/interop, the key determining factor is provided by the /proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to enabled. In fact, setting this to a "disabled" state will prevent any Windows PE code from running in the subsystem at all. Would it be acceptable to modify this submission to key off of this WSL interop process? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0JWt71FMTScd4gDglq2QB_ye-rErks5vYVojgaJpZM4VuN_h .

I think Wine could eventually be included, I would just have to find a reliable way to determine that it is installed.

WSL is a bit of a special case, though. What differentiates WSL from Wine is that there is no API call translation going on since the host offers native Windows resources. It's also distinct in that the presence of the WSL service implies that the user has at least a minimum installation of Windows binaries at their disposal (for instance, users can run tools such as regedt32.exe, net.exe, ipconfig.exe, etc...). The Linux environment under WSL blends so extremely well into Windows that users may as well settle for the fact that the OS is, in fact, a bare metal Linux machine. In this case, I think treating WSL like an OS feature set akin to 64-bit capability rather than an 'underlying' OS is a better philosophical approach than my original implementation.

In my personal use case, this is extremely important because I use a platform-agnostic Ruby application to run browser automation on Linux, macOS, and Windows hosts. By having my Windows hosts running WSL, it's much easier to port over proper behavior from my existing Linux-specific methods. This allows me to behave and log activity as though it's I'm still in a Linux context, but launch Windows-only browsers such as Internet Explorer and Edge for testing. Definitely makes my implementation easier to maintain.

rdp commented 5 years ago

maybe a new method is_wsl? :)

On Thu, Mar 21, 2019 at 8:49 AM Whitey notifications@github.com wrote:

I like your idea of a new method "windows exe's can run" or what not...wait should that include wine? maybe just cygwin and wsl for now? :) … <#m-7594663160987626906> On Tue, Mar 19, 2019 at 3:44 PM Whitey @.***> wrote: I've been thinking about this for a while and have since looked to the official documentation to see how these types of environments determine whether Windows PE executables can be run. According to the Interoperability Documentation https://docs.microsoft.com/en-us/windows/wsl/interop, the key determining factor is provided by the /proc/sys/fs/binfmt_misc/WSLInterop file existing and being set to enabled. In fact, setting this to a "disabled" state will prevent any Windows PE code from running in the subsystem at all. Would it be acceptable to modify this submission to key off of this WSL interop process? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#33 (comment) https://github.com/rdp/os/pull/33#issuecomment-474596539>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0JWt71FMTScd4gDglq2QB_ye-rErks5vYVojgaJpZM4VuN_h .

I think Wine could eventually be included, I would just have to find a reliable way to determine that it is installed.

WSL is a bit of a special case, though. What differentiates WSL from Wine is that there is no API call translation going on since the host offers native Windows resources. It's also distinct in that the presence of the WSL service implies that the user has at least a minimum installation of Windows binaries at their disposal (for instance, users can run tools such as regedt32.exe, net.exe, ipconfig.exe, etc...). The Linux environment under WSL blends so extremely well into Windows that users may as well settle for the fact that the OS is, in fact, a bare metal Linux machine. In this case, I think treating WSL like an OS feature set akin to 64-bit capability rather than an 'underlying' OS is a better philosophical approach than my original implementation.

In my personal use case, this is extremely important because I use a platform-agnostic Ruby application to run browser automation on Linux, macOS, and Windows hosts. By having my Windows hosts running WSL, it's much easier to port over proper behavior from my existing Linux-specific methods. This allows me to behave and log activity as though it's I'm still in a Linux context, but launch Windows-only browsers such as Internet Explorer and Edge for testing. Definitely makes my implementation easier to maintain.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rdp/os/pull/33#issuecomment-475260463, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAw0LP5JEAB5sFPLsy6vVPPRZdXByWAks5vY5v8gaJpZM4VuN_h .