2

I am seemkng for a sandbox for Linux secure enough to run malware in it securely. It should allow

  1. create different sandboxes

  2. run different programs in them, including the ones requiring admin privileges (in this case sandbox must give them simulated admin, indistinguishable from real admin if low level access to OS internals and hardware is not needed).

  3. restrict their access to different APIs, for example restrict internet access to non-whitelisted processes, driver installation, access to different folders, launching processes except the ones from whitelist, low level media access, etc ... The restrictions must be configurable.

  4. each sandbox should have its own folder/fs where modified files are stored, copy-on-write should be used to allow the sandboxed processes to write

  5. sandboxed processes within the same sandbox should be able interact with each other, but shouldn't with the rest of the processes (unless allowed).

  6. all the changes made in the main system should be available in sandbox

  7. You should be able transfer files from sandbox to the main OS easily

  8. You should be able to run apps utilizing GPU in it.

The example of such a sandbox for Windows is SandboxIE. Sometimes I had to run malware in the sandbox, the malware hasn't infiltrated the main system. There is even a malware analisys solution (bsa.isoftware.nl) based on SandboxIE.

Is there any solution for Linux which gives comparable security without virtualizing the whole OS in KVM/Xen? Is it possible to achieve this effect combining SELinux with LXC and some copy-on-write file system? Is there a solution which does this?

KOLANICH
  • 892
  • 6
  • 14

1 Answers1

4

Create different sandboxes

Linux currently supports six kernel namespace types:

  • IPC namespace
  • Network namespace
  • Mount namespace
  • PID namespace
  • user namespace
  • UTS namespace

run different programs in them, including the ones requiring admin privileges (in this case SandboxIE gives them simulated admin).

fakeroot can give programs simulated root access, but you'll find that this is actually not as useful as you think. A fully sandboxed program is a useless program and a program that's not sandboxed enough fails to fulfill the security requirements.

restrict their access to different APIs, for example restrict internet access to non-whitelisted processes, driver installation, access to different folders, launching processes except the ones from whitelist, low level media access, etc ...

In Linux, these access are restricted using regular system privileges mechanism. There are several systems:

  • traditional Unix filesystem permission: restricts who can access which files
  • capabilities: restricts the system calls that can be made by a root process
  • SELinux/AppArmor/TOMOYO: mandatory access control to enforce security policies

each sandbox has its own folder where modified files are stored, copy-on-write is used to allow the sandboxed processes to write

Linux supports copy on write filesystem like btrfs, or an overlay filesystem like UnionFS or OverlayFS may be used.

sandboxed processes within the same sandbox can interact with each other, but cannot with the rest of the processes (unless allowed).

This is kernel namespaces.

sandboxed processes in fact have the lowest integrity level, but they don't sense this at most cases.

Linux don't have a concept like integrity level. However, Linux allows much more fine grained integrity configuration with the capabilities system and the mandatory access control frameworks.

all the changes made in the main system are available in sandbox

You can do this with an overlayfs.

you can transfer files from sandbox to the main OS easily

This depends on how the containers are configured.

These are the kernel features that exists for programs that can be used by program to take advantage of. The userland programs you would use to use these kernel features are usually either Linux Containers (LXC) or Docker.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93