Hello! Let’s say I have an executable file, but I’m unsure of the source, and may contain bugs/errors/malwares/bad things that can mess up my machine. I want to execute it anyway, but I want to make sure that it does not mess things up. Is it possible to create a “sandbox” folder, place the executable inside it, and then give all files inside that folder only write privileges inside that folder, and not outside? so that echo "hello" >> log.txt would work, but echo "hello" >> ~/log.txt would not?
EDIT: thanks to everyone for the answers! I decided to opt for a VM to minimize the risk, but chroot is probably a faster solution for not-so-dangerous files
The old answer is a chroot jail, the new answer is a Docker container or VM if Docker won’t cut it.
I’m lazy, so Virtualbox is my VM software of choice. I keep a machine with a fresh debian install and just Clone it to make throwaway VMs.
Keep in mind that malicious software on a VM might be isolated from the host in many ways, but if it’s allowed to communicate on your network then it can still be dangerous, especially if you have samba shares, or services you don’t expose to the outside internet with weak or default passwords. (Did you change the admin password on your router’s Web interface?)
Creating a VM with no network interfaces is “mostly safe”, but you hear about VM bust out exploits now and then.
In reality, gold standard is a separate physical computer with no network connections to anything but other untrusted physical computers, and no wireless adapters (Bluetooth or WiFi). This is an “air gapped” network, but if you’re dealing with shit that makes you want an air gap, either you already know more than you’re gonna learn on Lemmy, or you’re bout to get your door kicked in by men in black suits :D
Also worth saying 99.9% of air gap failures are due to some idiot getting lazy with a usb stick or a phone. They’re a bitch to work with.
(Another 0.09% are someone plugging the wrong cord into the wrong switch by accident or stupidity)
Depending on what level of malware you’re worried about, running it in a Docker container could be a solution.
Assuming no kernel bugs are present and you don’t run the command as a user with direct access to any system devices (like /dev/disk-by-*), you can run a command in an environment that will get deleted afterwards with systemd-nspawn.
This will allow you to do various forms of sandboxing, including picking an alternative root directory. If you install a minimal version of your OS into a directory, you can effectively run an isolated container from a folder you specify
If you use BTRFS for your root filesystem,
systemd-nspawn -D / -xbwill also be able to start a full copy of your entire Linux system that’ll get erased after closing it.If your executable needs root or you’re not sure if it’ll exploit your kernel, a VM is the way to go. With tools like Vagrant you can set up VMs relatively easily.
To be completely safe I’d just use a VM, if you think that is an overkill then I suggest Bubblewrap.
Firejail is another option
I’ve created a tool for similar of use-cases: https://codeberg.org/contr/contr
You could run your workload inside, say, an alpine container:cd path/to/evil/dir contr alpine ❯ # inside container, run dangerous program ❯ ./dangerous_programIf the program needs extra dependencies, you’ll have to write a Containerfile and build an image with the dependencies installed – there’s an example in the repository. Just installing the dependencies at runtime inside the container is also an option, but all changes inside the container are lost on exit.
Look up
chrootYou might want to look into Firejail, kinda complicated to setup but it’s made for this.
I think chroot could achieve this too but I don’t know how secure it is
