Let’s be paranoid and secure our penguins
The goal of this article is to give a short overview of practical solutions to run untrusted proprietary applications under Linux while limiting the damage that they can do and to prevent possible privacy exploits.
There is a interesting section in the Arch Linux Wiki about Securing Skype that got me thinking about it:
There are a couple of reasons you might want to restrict Skype’s access to your computer: The skype binary is disguised against decompiling, so nobody is (still) able to reproduce what it really does and it produces encrypted traffic even when you are not actively using Skype.
Just assume the software has no security flaws, no remote exploitable bugs, AutoUpdate uses a secure HTTPS connection and checks the certificates, that it does not gather usage statistics or send crash reports that may contain sensitive information...
[chris@thinkpad ~]$ sudo ./proprietary_crap.bin
Pros: No additional work needed
Cons: No protection, the software may break your system, or worse
Comment: It just feels not right, I want a clean system without programs where I don’t know what they are doing in the background.
So this is probably the easiest solution, just add a new user account.
Easy to set up
[chris@thinkpad ~]$ sudo useradd evil [chris@thinkpad ~]$ sudo passwd evil Changing password for user evil. New password: Retype new password: passwd: all authentication tokens updated successfully. [evil@thinkpad ~]$
Easy to use “su - special_user”
[chris@thinkpad ~]$ su - evil Password: [evil@thinkpad ~]$ ps -Af|grep chris |tail -n1 chris 22265 1 0 02:04 ? 00:00:17 okular /var/tmp/sandboxing-notes.pdf --icon okular -caption Okular [evil@thinkpad ~]$ ls /home/chris/.gnupg/ ls: cannot access /home/chris/.gnupg/: Permission denied [evil@thinkpad ~]$
No extra work needed to start X11 applications
[evil@thinkpad ~]$ firefox &  7628 [evil@thinkpad ~]$
Full network access, using iptables to restrict network access for a single user way too complex and thus prone to security lapses
Running on the same X server
Any application that has access to the X server can do a lot of things. It can snoop on other applications that display windows on the same server. It can log key presses. It can rebind keys. It can inject key presses into other applications. It has access to the clipboard. –https://security.stackexchange.com/questions/6209/running-proprietary-software-on-linux-safely
See the full process list with command arguments “ps -Af” and more...
What about SUID binaries?
- The user evil should not be allowed to use sudo.
- At least it protects your files in your home directory a little bit.
A chroot on Unix operating systems is an operation that changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name (and therefore normally not access) files outside the designated directory tree.
- You can install a different set of libraries that may be needed by the proprietary application without modifying your host system.
- Possible to run a different version of the same OS
- Does not protect against intentional tampering by privileged (root) users inside the chroot
- Probably full network access
- Chroot alone doesn’t bring any kind of security. In other words, treat a chroot as if the chrooted processes could access everything on the system — because often they do. –https://unix.stackexchange.com/questions/17299/debian-unstable-chroot-security-issues
- Chroot is not intended to force a program to stay in that simulated filesystem; a program that knows it’s in a chroot “jail” can fairly easily escape, so you shouldn’t use chroot as a security measure to prevent a program from modifying files outside your simulated filesystem –https://unix.stackexchange.com/questions/105/chroot-jail-what-is-it-and-how-do-i-use-it
- I haven’t tested it any further, normally I’m just using chroot to fix a broken system from a live CD.
- Introducing the SELinux Sandbox https://danwalsh.livejournal.com/28545.html
- Cool things with SELinux... Introducing sandbox -X https://danwalsh.livejournal.com/31146.html
[chris@thinkpad ~]$ sudo yum install policycoreutils-sandbox [chris@thinkpad ~]$ sandbox -t sandbox_web_t -i /home/chris/.mozilla -w 1672x968 -X firefox
Pros: Very lightweight
Cons: Difficult to set up
Comment: Very cumbersome to to get it right, easy to overlook possible security or privacy flaws.
- requires a modified Linux kernel, complicated to set up
- LXC (LinuX Containers)
- LXC is included in the vanilla Linux kernel and requires no additional patches.
- Based on LXC and cgroups with a nice interface and image management.
- Good security: http://blog.docker.com/2013/08/containers-docker-how-secure-are-they/
- See here for my full Docker guide: Sandboxing proprietary applications with Docker
- Arkose - Desktop application containers made user friendly.
- Desktop Containers, Sandboxed applications for GNOME:
- Minimal overhead compared to a virtual machine
- Containers start very fast
- nearly zero CPU consumption
- You can only run a Linux operating system inside a container
- Looks very promising
- Very easy to use
- Limitations: proprietary extension necessary to use USB devices
- QEMU, KVM, virt-manager, GNOME Boxes
- Good USB support
- I never got Windows and Spice to work together as seamlessly as with VirtualBox (seamless resizing of the display, shared clipboard, shared folder). But I will try it again sometime.
- VMware - proprietary itself...
- Good resource and security isolation
- You can run a different operating system like Windows
- Running a complete operating system
- Slow startup time while waiting for the OS to boot
- Really resource hungry (have to assign at least 1 GB of RAM to each VM, 5 GB and more for every virtual machine image)
- If you need Windows software then this is the way to go.
They are just too much of a pain to use regularly:
- Dual-booting: different partitions for Windows and Linux, but dual-booting with encrypted disks won’t help mush because the boot partition cannot be encrypted
- Using a live system
- Use a separate PC without network access.
So I hope I haven’t forgotten any possibility^^
Everything less secure than a LXC container with limited network access makes not mush sense.
For resource intensive applications that run under Linux (like Xilinx ISE, basic installation needs 20 GB of disk space...) container virtualization with Docker is probably the best solution, have a look at my full Docker guide: Sandboxing proprietary applications with Docker.
For everything that needs Windows either use VirtualBox or dual-boot.
Further ideas and corrections are very welcome.
PS: I’m really not that paranoid^^ But I like to tinker with software and experimenting with Docker was really interesting ;)