I recently read an article in eWeek that talked extensively about Application Whitelisting. The more of the article that I read this seems to be nothing more than SELinux on Windows.
The Windows people are looking to lock down their machines because of the horrendous numbers of viruses, trojans and other malware that attacks them. Apparently user education, anti-virus and anti-whatever just is not getting the job done.
Windows machines in the past have used the traditional methods for fighting malware. Anti-virus tracks and quarantines certain bits that are known malware problems. This is known as blacklisting. Whitelisting is the process by where certain executables are approved to run on a certain machine.
Now let’s have a look at SELinux which was first implemented by Red Hat several years ago. While Linux in general does not have a problem with malware an unprotected machine could get hacked and unwanted applications installed. Red Hat wanted a way to stop this type of intrusion. Let’s look a little deeper how this came into play.
SELinux was originally a development project from the National Security Agency (NSA ) and others. It is an implementation of the Flask operating system security architecture.The NSA integrated SELinux into the Linux kernel using the Linux Security Modules (LSM ) framework. SELinux motivated the creation of LSM, at the suggestion of Linus Torvalds, who wanted a modular approach to security instead of just accepting SELinux into the kernel.
You can see the rest of the article here
So here we have a security application mostly developed by the NSA.
Much of the work to get the kernel ready for upstream, as well as subsequent SELinux development, has been a joint effort between the NSA, Red Hat, and the community of SELinux developers.
Now let’s look at how SELinux runs under Red Hat and any other *nix that uses it. Red Hat uses what is called a target policy for SELinux. SELinux creates what are known as domains. Each daemon has it’s own domain. Every daemon on the system runs under the unconfined_t domain except for those that have targeted specific domains. Daemons that run under the unconfined_t domain fall back to using standard Linux security. As an example the http and ntp daemons run under the targeted policy by default and are therefore protected. If you haven’t experienced what happens under this protection, if one of the binaries or configuration files get put into the wrong context the daemon will not start.
This should be starting to sound familiar to the definition of Application Whitelisting above. It will be interesting to see if the Windows shops buy into this method of protection. I also expect some announcement from Microsoft or some other big firm how they have developed this new concept and are providing it as a tool to protect Window applications. I wonder how much the licensing fee and yearly maintenance will be on that…