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

  • ThreeHalflings@lemmy.world
    7·
    1 year ago

    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

    • ThreeHalflings@lemmy.world
      4·
      1 year ago

      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)

  • spencer@lemmy.ca
    5·
    1 year ago

    Depending on what level of malware you’re worried about, running it in a Docker container could be a solution.

  • jntesteves@lemmy.world
    2·
    1 year ago

    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_program

    If 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.

  • Mininux@sh.itjust.works
    2·
    1 year ago

    You 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