2008/9/17 McGuffey, David C. <DAVID.C.MCGUFFEY@xxxxxxxx>
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.
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@xxxxxxxxxx
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.
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
