How can I run an untrusted executable on linux safely?

Question

I have downloaded an executable compiled by a third party and I need it to run on my box (Ubuntu 16.04 - x64) with full access to HW resources such as CPU and GPU (through nVidia drivers).

Suppose this executable contains a virus or backdoor, how should I run it?

Should I create a new user, run it with it and then delete the user itself?

edit

Not approving the answer below yet because firejail might not be working.

edit 2

firejail is ok but one has to be extremely careful in specifying all the options in terms of blacklist and whitelist. By default it does not do what is cited in this linux-magazine article (see also some comments from firejail author).

Be extremely careful when you use it, it might give you a false sense of security without the right options.

Answer 1

First and foremost, if it's a very-high-risk binary... you would have to set up an isolated physical machine, run the binary, then physically destroy the HDD, the motherboard, and basically all the rest. Because in this day and age, even your robot vacuum can spread malware. And what if the program already infected your microwave through the pc speaker using high-frequency data transmit?!

But, let's take off that tinfoil hat and jump back to reality for a bit.

No virtualization, quick to use: Firejail

It is packaged already on Ubuntu, it is very small, has virtually no dependencies.
How to install on Ubuntu: sudo apt-get install firejail

Website: https://firejail.wordpress.com/

Package info:

Package: firejail
Priority: optional
Section: universe/utils
Installed-Size: 457
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Reiner Herrmann <[email protected]>
Architecture: amd64
Version: 0.9.38-1
Depends: libc6 (>= 2.15)
Filename: pool/universe/f/firejail/firejail_0.9.38-1_amd64.deb
Size: 136284
MD5sum: 81a9a9ef0e094e818eb70152f267b0b6
SHA1: 41d73f8b9d9fd50ef6520dc354825d43ab3cdb16
SHA256: f1cbc1e2191dbe6c5cf4fb0520c7c3d592d631efda21f7ea43ab03a3e8e4b194
Description-en: sandbox to restrict the application environment
 Firejail is a SUID security sandbox program that reduces the risk of
 security breaches by restricting the running environment of untrusted
 applications using Linux namespaces and seccomp-bpf.  It allows a
 process and all its descendants to have their own private view of the
 globally shared kernel resources, such as the network stack, process
 table, mount table.
Description-md5: 001e4831e20916b1cb21d90a1306806f
Homepage: https://firejail.wordpress.com
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Origin: Ubuntu  

I had to run a similar "untrusted" binary just a few days ago. And my search led to this very cool small program.

Virtualization: KVM, Virtualbox.
This is the safest bet. Depending on the binary. But hey, see above.
If it's been sent by "Mr. Hacker" who is a black belt - black hat programmer, there is a chance the binary can escape the virtualized environment.

Malware binary, cost saver method: Rent a machine! A virtual one. Example virtual server providers: Amazon (AWS), Microsoft (Azure), DigitalOcean, Linode, Vultr, Ramnode. You rent the machine, run whatever you need, then they will wipe them off. Most of the bigger providers bill by the hour, so it really is cheap.

Answer 2

From Firejail man page:

   Without  any  options,  the sandbox consists of a filesystem build in a
   new mount namespace, and new PID and UTS namespaces. IPC,  network  and
   user  namespaces  can  be  added  using  the  command line options. The
   default Firejail filesystem is based on the host  filesystem  with  the
   main  system directories mounted read-only. These directories are /etc,
   /var, /usr, /bin, /sbin, /lib, /lib32, /libx32 and /lib64.  Only  /home
   and /tmp are writable.

This is a high level description, there are other things going on, for example /boot is blacklisted, and so are /sbin and /usr/sbin.

https://firejail.wordpress.com/features-3/man-firejail/

You can also look at this document: https://firejail.wordpress.com/documentation-2/firefox-guide/ - they have a very good description of the file system.

Answer 3

Just run it on a separate install - set up a seperate install on a external drive or another hard drive, make sure your main install's paritions are not mounted (or better yet, disconnect them), and test. You can back this up preinstall in case you need it again, and nuke it once you're done.

Its a much more robust method than sandboxing/jailing, and you can confidently treat the second install as disposable and/or use it only when needed.

Answer 4

Just run live from an ISO

All filesystem changes are only stored in RAM, and lost/reset on reboot (provided nothing wrote to any storage drives). Bare metal hardware can be directly accessed, and no worries about jailbreaking or VM escaping. You're only limited in / filesystem space available to write new files.

You could also completely disconnect your main hard drive (if you're worried it could get overwritten, if not read & shared) and run the ISO from a USB drive (ex. thumb drive, external hard drive), or even a second hard drive - similar to Journeyman Geek's answer, but it's a lot easier to make a bootable USB than a full install (imo).

If you have enough RAM (maybe 4GB+) you might be able to copy the entire filesystem into RAM, and then unplug the USB drive, so even the USB can't be written to.

• If supported, the boot option to copy everything into ram is often something like "toram".

With many ISO's it's even possible to copy the ISO file to, for example, the boot partition of your currently installed hard drive, and then use grub to boot from the ISO directly. Although it doesn't work for every ISO, and might need some special boot parameters (for example MX-Linux can use fromiso=[iso file] blab=[partition label], etc. It's quite robust, with tools to create an ISO from a running system, write the iso to a USB drive (persistence optional), and even a "frugal install" where basically the contents of an ISO are booted from a hard drive partition).

• Watch out for programs that automatically create a bootable USB with persistence. Those would save changes to the USB, but even persistence could probably be disabled with some boot options.

• There is firmware that could be corrupted in your motherboard, storage drives, GPU/video cards, and of course networked devices, if you're considering handing complete control over to this mystery executable. Apache was basically correct in his tin foil hat intro.