, , , , , , , , , , ,

Bruce Schneier made a statement last September to the effect: If the NSA wants in on your computer, it’s in. I’m not so sure. When putting together a report around roughly this issue, I arrived at the conclusion there is indeed a methodical way to bulletproof a UNIX system.

Host security is normally dependent on commercial anti-malware products, patching and various administrative controls, any of which could be a single point of failure. Almost no system had the layered security model I’m attempting to formalise. On top of that, relatively few systems are protected against the unknowns – the truly sophisticated malware and the zero-days.

What I’m proposing is an extremely secure configuration for UNIX installations by combining stuff at a very low level. What’s more, the components to do this are free, and in combination they provide a type of security unattainable by expensive ‘high-tech’ security products exposited in glossy brochures.

At the moment the model looks something like this:


The following are just a few notes, until I refine the idea and write something up in more depth.

Stack Protections
What this measure provides is the option to add stack protections when compiling software, specifically using fstack-protect with GCC. I’ve put this near the user level because it’s an option for users and developers, depending on whether the software’s distributed as source. Unfortunately it’s only useful where users are compiling their software from source, on systems where very few proprietary components exist.

Address Space Layout Randomisation
Again, patching only provides security against the known vulnerabilities, and these days the zero-day stuff is becoming a real concern. The next layer in the model randomises some of the process addresses – an exploit developer must somehow determine where the return address lives, the buffer sizes, the buffer addresses and whatnot. If some of the addresses are unpredictable enough, the task of creating a working exploit becomes extremely awkward.

No add-ons are needed as such. Apparently ALSR has already been included in mainstream Linux since 2005, and it’s definitely native to Ubuntu, Linux Mint and Oracle distributions. The value in /proc/sys/kernel/randomize_va_space indicates the mode it’s being used in. If it has a value of ‘2‘, the positions of the stack and the .data segment are randomised for programs configured to use ASLR protection.
The bad news is ASLR is not universally applied, being another compile-time option.

This is more relevant to UNIX machines operating as servers, but anyone using Linux Mint or Ubuntu can install it from the package repositories. Configured correctly, it can prevent Denial of Service attacks, port scanning, port redirection and allow connections only from predefined IP addresses. Access control and resource usage limiting are the main reasons to configure xinetd on a server. The first line of protection for bastion hosts. More detailed write-up here.


iptables and netfilter
Ultimately how firewall policies are implemented in a Linux system, netfilter is a kernel module that drops, accepts or forwards incoming packets before the OS does anything with them. The netfilter module policies are administrated by the iptables command line executable, and the degree of control it allows is highly granular.


Alternatively netfilter/iptables can be ultimately administrated through desktop GUI applications such as gufw, if configuring it through the command line proves too much of a learning curve.

Linux Security Modules Framework
A native feature of the Linux kernel since version 2.6, the Linux Security Modules (LSM) framework on its own adds almost no security. It provides an interface for optional modules that intercept system calls to critical kernel functions, in other words implementing various forms of access control for programs running in user space. This is an important distinction from security measures that apply to users.

The National Security Agency has been getting a lot of bad press lately as a result of the Snowden/Greenwald drama. What’s less commonly known is the NSA also has an ‘Information Asurance Directorate’ (now the Trusted Systems Research Group), tasked with actually making stuff secure.
One good thing the NSA did produce enhances security by adding a module to the LSM framework – Security Enhanced Linux (SELinux), plus a load of documentation to go with it.
SELinux has been around a while, it’s still actively being maintained, and it’s available from the Ubuntu and Linux Mint repositories.


The general idea is the SELinux module enforces a kind of role-based Mandatory Access Control (MAC), where programs and daemons are granted the least privileges required to function. Even if applications running with root privileges are compromised through unpatched vulnerabilities, the potential damage is quite limited.

Each process is assigned a user name, role and domain. SELinux determines what processes belonging to a given domain are allowed to access. The role tag is used by SELinux to separate administrative from non-administrative processes, which in turn limits the scope of programs that could be compromised and made to perform administrative actions.

SELinux received some criticism for being rather tricky to implement, so along came an easier alternative called AppArmor. It is also included or available in mainstream distributions, in particular SUSE/openSUSE.


AppArmor provides a security module that enforces security policies accrording to the profile set for each program on the system, with the idea that programs are then given only the access to resources that their profiles define. This is rather like SELinux, but AppArmor can be configured to operate in ‘learning’ mode.

Anyone with a spare box could install Ubuntu, grab the components I’ve described here from the repos, have a play around with them and have a far more secure installation as a result.