4

A great quote from this InfoSec stackExchange thread.

The way to prevent malicious code from damaging files in your home directory is to not run it using your account. Create a separate_user that doesn't have any special permissions and run code under that UID until you've determined whether or not you can trust it.

Most code I run, that has the potential to be malicious, is niche scientific applications that install via sudo apt-get install suspect_program. apt-get will give the suspect_program root access during install. The code can therefore run anything malicious it wants anywhere it wants on my system.

How does running the code under a seperate_user account protect any other accounts on my Ubuntu Linux box? I already gave the suspect_program root access when I installed the darn thing.

4

If you gave the program root access, you can't prevent it from accessing your account.

(By “root access”, I mean “the highest level of privileges”. It's possible to run programs as the user root without granting them the highest level of privileges, through security frameworks such as SELinux. However, to get actual protection, you'd have to run the package manager with restricted privileges, in a way that doesn't let it escalate its privileges by e.g. creating a setuid binary or a cron job. I think this is possible, but it would be very hard to set up and I'm not aware of an existing framework that does this.)

To really isolate the program (including its installation scripts), you should install and run it in a virtual environment. If the program doesn't need to access hardware directly and doesn't need to squeeze out top CPU performance, run it in a virtual machine. If that's not feasible, run the program in a container, which creates a virtual userland environment on the same kernel as your main environment. Since the program is running on top of the same kernel, its performance is not affected by running in a container, and the container has access to any device you choose to let it access. A program running as root in a container is only root inside the container, and cannot access files that are not shared with the container. Docker is a popular software to manage and distribute containers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.