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 -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
