Whitelisting only digitally signed binaries

[Chris Snook]

McGuffey, David C. wrote:
> There is quite a raging debate in the Information Assurance arena about
> the failure of blacklisting and that we need to migrate to whitelisting,
> or at least a balance between blacklisting and whitelisting.  We spend a
> lot of time developing security functions (like SELinux, ClamAV, etc.),
> which is a good thing, but why not also add the capability to keep
> tampered/unauthorized executables from executing in the first place?
> 
> Many years ago, while in the National Computer Security Center, I
> watched a young researcher develop a "trusted loader" for Unix that
> would only load a executable that could pass an integrity check. I don't
> know what ever happened to that research project...whether or not it
> ever turned into a real world capability.
> 
> "Tripwire" and its genre of tools are an after-the-fact integrity
> checking approach.  This approach is good for detecting
> tampered/unauthorized executables AFTER the attack has taken place, but
> doesn't keep one from executing the potentially malicious executable in
> the first place.
> 
> Has any work taken place in the Linux community toward building a
> "trusted loader" into Linux.  If so, what is the status? If not, why
> not?
> 
> I would envision something that checks a digital signature or at least
> checks a table of hash strings associated with the true/trusted version
> of the executable before allowing the loader to proceed. One would have
> to update the table when an update for the executable is issues.  Maybe
> the update is tied into yum. I realize that an infrastructure would have
> to exist for developers to sign their apps, and store their public
> certificates/keys, but this doesn't seem too far out of reach, after
> all, we already do this manually when we download a new Fedora release.
> 
> Dave McGuffey
> Principal Information System Security Engineer // NSA-IEM, NSA-IAM
> SAIC, IISBU, Columbia, MD
> 
> 

This gets rather messy when you're using dynamic linking, and the alternative - 
static linking - creates more security problems than it solves.

Intel created the Trusted Platform Module, available on their business-oriented 
chipsets but often disabled in the BIOS by default, to give the kernel some 
hardware help in sorting out this mess, and the kernel knows about it.  I 
imagine someone has developed userspace tools to configure TPM, though I can't 
think of any offhand.  You may want to look into that.

I suspect you'll find that using a strict SELinux policy (instead of the default 
targeted policy) is probably much more manageable than dealing with signed code.

-- Chris