Nils Philippsen wrote:
On Thu, 2008-08-28 at 20:07 +1000, Bojan Smojver wrote:
On Thu, 2008-08-28 at 10:49 +0200, Nils Philippsen wrote:
Just about every bank in Germany would operate like this. After all, we
do have a national ID that is hard enough to fake(*) and if you present
it to entities like banks, they usually make a copy and can verify the
data on the ID with the "Einwohnermeldeamt" (possibly "residents
registration office").
In other words, they only marginally trust that ID card. Therefore, they
cross-check with the office (but most likely NOT the person that issued
the card) that what is on that document is ACTUALLY true.
I don't know if they do that at all or with everybody, in fact I'm
pretty sure they will accept the IDs at face value. Maybe they verify
old documents that don't have all the gizmos that make the ID hard to
fake today. I just wanted to point out that they can do that.
Think of the card as the RPM coming out of Fedora build system, signed
with Fedora key (i.e. all the hard to get paraphernalia that the card is
made of). Think of the phone call to the office as a comparison to an
independently built RPM. Think of the act of opening the bank account as
an independent signatory signing the RPM.
All this doesn't help much if somebody manages to feed the process with
corrupt data in the beginning -- be that a fake ID when applying for
replacement for an expired ID, or somebody corrupting the repository
that keeps the source that is fed to the builders. Besides the
difficulties in making distributed build verification work solidly, we
have to harden the system/process that feeds the builders in the first
place -- which is already much easier than say hacking the builders.
Otherwise it's just GIGO, all pain and no gain.
Nils
It is (almost) all about process. Documented, auditable, verifiable
process that is reviewed periodically by someone other than those using
it to make sure it is in fact being followed, verified, audited, etc.
In a sense, fedora and rht just had a hostile audit. They failed. Now
close the feedback loop and use what you've learned to fix the process.
New keys are nice, but ultimately useless w/o a better process to
safeguard them, to ensure their correct usage, by the correct people on
the correct content, and to enable their revokation if it happens again.
As Schneirer says, good security is hard. This is not a new path,
nothing needs to be invented, just some good solid principles
(separation of duty, verification of trust, independent review and
audit, etc) followed.
Apparently, there was not enough process in place, or the processes that
were in place were not followed, or they are (hopefully were) the wrong
processes.
--
----------------------------------------------------------------------
Jim Wildman, CISSP, RHCE jim@xxxxxxxxxxxxx http://www.rossberry.com
"Society in every state is a blessing, but Government, even in its best
state, is a necessary evil; in its worst state, an intolerable one."
Thomas Paine
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
