Whitelisting only digitally signed binaries

[Bingo]

2008/9/17 McGuffey, David C. <DAVID.C.MCGUFFEY at saic.com>

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



I might have misunderstood you, but what will stop the malicious attacker
from signing his tampered executables? Maybe the signing ability will only
be granted to "registered" developers. But in linux, everyone is a developer
in the sense that running and distributing among friends of self-compiled
executables is popular. Not all users actually write code, but a large
majority compiles with slightly different options than fedora RPMs.

So such users might have to disable this whitelisting stuff. Who would
control the grant of signing ability?

PS:
You CC'ed yourself so I assume you may not be subscribed to the list. Sorry
if you didn't want to be CC'ed on the replies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080917/44020bf4/attachment-0001.htm>