Budget TPE in a shell script

Most of you recall that a few years ago, the state of the art on Windows was executable whitelisting. We have of course been over why it's not The Right Way To Do Things (several times at that). However it does have some advantages:
- It provides some defense against social engineering and human error. And it does so more reliably than antivirus programs, and more easily than full mandatory access control.
- It is still (!) effective against the vast majority of malware on desktop platforms.

It is also utterly simple to implement on Linux, using six lines of shell script in /etc/rc.local (or equivalent).

READ THIS FIRST
Putting aside the much-discussed disadvantages of TPE, there is one more problem: Debian and Ubuntu per default execute package install scripts from /tmp. Fortunately this is easy to change; you only have to set up an apt config file with this in it:

Code:

APT::ExtractTemplates::TempDir "/secure/tmp/path"

with the path of course having root:root 0755 permissions. APT works fine with this.

Now the simple part

Code:

for DIR in /home /tmp /var/tmp /media /mnt /run; do
 # Skip the directory if it is already mounted
 if ! grep "$DIR" /proc/mounts; then
  mount --bind $DIR $DIR
  mount -o remount,nodev,nosuid,noexec $DIR
 fi
done

And yes, it works. Even if you try to be sneaky with binaries.

Code:

~$ ./.xsession
bash: ./.xsession: Permission denied
~$ ls -l .xsession
-rwxr-xr-x 1 triton triton 45 Mar  7 22:29 .xsession
~$ cp /bin/less .
~$ ./less
bash: ./less: Permission denied
~$ ls -l less
-rwxr-xr-x 1 triton triton 145320 Mar  8 03:23 less
~$ /lib/ld-linux.so.2 ./less 
./less: error while loading shared libraries: ./less: failed to map segment from shared object: Operation not permitted

Needless to say it won't work against malicious scripts or bytecode files, but that's not really the point.

"The point?"

See again "social engineering and human error." If some program has a logic flaw/feature that allows a malicious binary to be downloaded or executed, this can stop it. ASLR and NX can't. Likewise simple things like accidentally running something from your file manager that turns out to be a trojan.

"I want to compile and run my own arbitrary binaries as a limited user, this gets in the way."

This is more aimed at end user applications (e.g. office workstations) than use by developers. That said, if you are a developer you could
- Have a dedicated user account for development purposes
- Use a chroot sandbox for developing userspace stuff (probably good idea in any case)
- If you have a recent x86 machine, use VMware/Virtualbox/KVM

"How is this better than AppArmor/SELinux/GrSec/etc.?"

It isn't. Actually SELinux provides ways of implementing it (better) and GrSec includes real TPE as an option. However, it is portable, takes a minute to set up, and might prevent Bad Things. Consider it yet another level of system hardening.

"Okay, I'm sold!"

Don't be. TPE is not a cure-all, and this is the budget version. It doesn't work with scripts, it doesn't work with Java, and perhaps most importantly it doesn't work with Windows binaries under Wine. It's just another layer of protection. Do some research on what threats your Linux systems face, then decide whether it's worthwhile, or will just provide a false sense of security (which in a lot of cases can be worse than nothing).

"But do you intend to use it?"

Yes. Hey, I should be developing my hobby projects in isolated environments anyway...

 

Hi, gJones.
Here's my current reading list for the topic "lightweight virtualization // application isolation"
(systemd+docker is not in my sights)(not "lightweight")

Finally, I see light on the horizon regarding the prospect of easily attained per-application network access restrictions.

Program_Space
http://freedomboxblog.nl/sourcecode_psc

pFlask
https://github.com/ghedo/pflask


LXC - Linux Containers
-
https://linuxcontainers.org/
https://qa.linuxcontainers.org/master/current/doc/man/
https://github.com/lxc/lxc

The docs for psc and plask are easier to digest than the LXC docs.
I have the impression that the virtenv approach is comparatively "dated".
virtenv (overlayFS +QT LXC gui)
-
Network and Filesystem Isolation with LXC and virtenv
http://l3net.wordpress.com/2013/04/13/network-and-filesystem-isolation-with-lxc-and-virtenv/
http://virtenv.sourceforge.net

http://l3net.wordpress.com/2014/02/01/debian-virtualization-back-to-the-basics-part-3/

http://www.ibm.com/developerworks/linux/library/l-mount-namespaces/index.html