For instance Sandboxie on Windows. Could a sandboxed program use DLL injection to migrate its execution to another process outside the sandbox?
No, a program running in Sandboxie can't interact with other processes that is the purpose of a sandbox. To do so would require a sandbox escape vulnerability
Related
There are many ways to run a WebAssembly module, besides Web, Node.js can load wasm module with --experimental-wasm-modules, standalone runtime like wasmtime and lucet can run it too.
So how do I detect the current environment in WASM and is it possible to apply a restriction on wasm modules that make it can only work on a specific website?
WebAssembly has no built-in I/O capabilities - it cannot access the DOM, read the filesystem, renders to the screen etc. In order to perform any of these tasks it needs to interoperate with the host environment (most typically JavaScript).
As a result, WebAssembly cannot detect its runtime environment. It could ask the host what environment it is executing within, although this could of course be faked!
Getting powershell running on Linux is straightforward.
Unfortunately this is based on .NetCore which excludes a lot a important functionality and modules e.g the DNSServer module.
Is there a workaround to obtain a fully functional PowerShell installation on linux including modules that don't appear in .NetCore (specifically DNSServer) ?
Modules like DNSServer are owned and maintained by the DNS team within Microsoft and aren't part of the PowerShell project itself. This also means they aren't open source.
On top of that, for DNSServer specifically, that module uses WMI under the hood (I'd go so far as to say it's a thin wrapper around the WMI calls), and since WMI is also not open source and not available on Linux I'd say there's little chance of this module making there any time soon.
As a general case, your best bet is probably to use PSRemoting from Linux to a Windows machine that has the modules you want, then either use Implicit Remoting (Import-PSSession) or just straight up make remote calls with Invoke-Command.
ERROR: In /home/kitware/dashboards/buildbot/paraview-debian6dash-linux-shared-release_opengl2_qt4_superbuild/source-paraview/VTK/Rendering/OpenGL2/vtkXOpenGLRenderWindow.cxx, line 286
vtkXOpenGLRenderWindow (0x529c2b0): bad X server connection. DISPLAY=Aborted
I understand that the main reason why it is not running is because it needs to use a window which it cannot create remotely.
I am able to run it locally
This is a benchmark provided by paraview.org
The issue arises because the process needs access to an X server to create a Window and then an OpenGL context for all the rendering. The default linux binaries shipped by paraview.org use rely on X to provide the context. If your sever is not going to provide X access to your processes (which is not unheard of), then you should build ParaView with either OSMesa support or EGL support and use that build instead. In those builds, ParaView uses non-X dependent methods to create the OpenGL context.
I have a Perl application on Windows which uses threads which run in parallel. Each thread accesses an MSSQL database.
I understand that I can't use Win32::OLE because it is not thread safe.
Could you suggest me some another suitable solution for doing this?
Create a Windows service, which will access the database as a single thread and Perl will use this service?
Create another Perl app "server", which will access to DB as single thread app, and the Perl threads will use this service?
Use Win32::OLE (DBI) library only in child threads or by some safe way?
I don't know what the right way is, and what the ways to solve it might be.
DBI isn't dependent on anything other than the usual build and test modules that are used during installation
There is no DBD driver for SQL Server (I'm not clear why. Perhaps someone would enlighten me?) so you will need to use an ODBC connection using the DBD::ODBC driver
I'm unsure how DBI behaves under threads, and I suggest you use fork instead which is emulated on Windows versions of Perl. You will need to set $dbh->{AutoInactiveDestroy} = 1 to prevent processes from auto-destroying database and statement handles when they shouldn't
As suggested by #Borodin why not use DBIx::Class ?
It is thread safe. Maybe you should explain better the way your application have access to database. It seems that you have a "Windows server" that is a sort of Perl Module that use Win32::OLE and this server acctually talks with the database.
I am hooking to another application process using AppInit_dll, but this hooking is not working in Windows 10 machine.
If I disable secure boot UEFI it is working as expected.
Can anyone know alternative for AppINIT_dll
You can go for dll injection. Once the dll injection is done, you need to run a method infinitely and use another thread for your code to run in parallel.