Whitelisting only digitally signed binaries
Chris Snook
csnook at redhat.com
Wed Sep 17 19:39:58 UTC 2008
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
More information about the fedora-list
mailing list