warning to list
nphilipp at redhat.com
Fri Oct 29 12:13:47 UTC 2004
On Thu, 2004-10-28 at 19:32 -0300, Alexandre Oliva wrote:
> On Oct 28, 2004, Matias Féliciano <feliciano.matias at free.fr> wrote:
> > As often as the server is insecure.
> > Do you mean the build server is a total disaster about security ?
> It means lots of people have build access to it. If having build-user
> access to it implies being able to attach a signature to the package,
> it means anyone with build access is able to obtain the signing key.
Come on, you know that you needn't do it that way. For Rawhide, all we
(that is some people including me) want to have is that the packages
that originate in the Red Hat build system are signed with a short-lived
key that we can be sure that the package is in fact the one piped
through the build system. This can be made part of the pushing step in
I don't know whether pushing the packages happens manually (in which
case it would be only very few people how could initiate it, right?) or
whether it happens per cron job. In the first case, it should be easy,
in the second you could -- for the sake of the security of the key --
make the signing part a separate daemon. The pushing process would then
hand over the packages to be signed to the daemon which would sign them
and return the signed packages to the pushing process. That daemon could
even be sitting on a separate machine to make it a bit more secure ;-).
Note that this is just a rough idea, it will likely have the odd edge
that needs to be rounded.
> > If it's the case, why should I even trust unsigned rpm ?
> Oh, so we're getting somewhere here. Maybe you shouldn't?
> > Just curious, How many time the build system have been cracked ?
> None that I'm aware of. And this wouldn't have affected the key
> anyway, because they key is not part of the build system. But in
> order to have automated signatures stapled to packages, it would have
> to be, and the key could easily leak.
No. See above. Or in different terms: Even a signed package in FC final
or update, RHEL final or update or whatever doesn't tell me more than
that this particular package has been piped through the Red Hat build
system. It doesn't automatically mean that the package would have been
audited for not having malicious code in it, which in turn means that
Beehive could even just hand off every built package to a separate
"signing entity" which holds the keys safely for itself and we wouldn't
lose a thing we already have in terms of security. It means that the
package has been built "here" and nobody has changed it in the meantime.
> But with a signed rpm, you get a false sense of security because you
> may think you can trust it. But you can only trust it, to whatever
> extent you choose to trust it, if the key is known to be safely
> guarded. If it isn't, you're just fooling yourself. The signature is
> actually working against you.
No, because the build system wouldn't have the keys.
> Err... Come again?
> Who's forcing anyone to trust unsigned packages?
> I haven't signed this message. Am I forcing anyone to read it? I
> don't think so.
That is not the question. This mail isn't signed as well because it
doesn't really matter whether it's really me who wrote it, I hope the
arguments count more than the person who's written them ;-).
> If you read it or not, and if you choose to believe I wrote it or not,
> is up to you. I'm not forcing you anything. I'm not even compelling
> you to write a reply (quite the contrary ;-), but you will anyway :-)
> > The current situation is worse than "one day, some people wrongly
> > trust a key".
> You got a very twisted view of good/bad IMHO.
> > Do you think it's a good security practise ?
> Certainly not. Personally, I'd much rather have all packages in
> rawhide signed. But with a properly-created signature.
Exactly :-). Please show me whether there are any flaws in what I've
> Failing that, I'd be more than willing to live with a signed-rawhide
> repository, that we could build the way I described in a previous
At the point you (or an automated system) can sign package repository
data, you (or it) can also sign the contained packages.
> Failing that, well... Maybe we could create a community of volunteers
> who would keep monitoring the mirror sites looking for corrupted
> packages, and maybe even offering rawhide mirror-like sites with
> additional signatures attached to the packages.
Monitoring the repos for corrupt packages is reactive security which is
nice to have but not the only thing I would want to rely on.
> If any single mirror is corrupted, it's too late for people who got a
> package from there and didn't check it before installing. Yes,
> checking is a pain.
I'm sorry, but I'd say checking that a binary package which isn't signed
at all (i.e. I can't know that it really comes from the original source)
doesn't contain malicious changes is a bit too much to expect from
people who aren't compiler engineers and eat assembler for
breakfast ;-). After all I thought we would want people to download
Rawhide stuff and test it, then they should be sure that even if the
package destroys their data, spams the net and causes their machines to
melt down into a smoking pile of rubble, it is from Red Hat and they
shouldn't blame themselves for being hacked but for using the package on
a valuable system ;-).
> You're missing the point. Why would I trust a random key I obtained
> from an ftp site?
> Such a key would have to be signed by another Red Hat key to be of any
> value. No big deal for those who understand the issue, but how many
> people you think would check the signature in the key, to verify that
> it's legitimate?
I (as an outsider which I am not) would trust a short-lived key that is
signed by Red Hat's key which is signed by some CA. Fairly secure if you
ask me, provided that each of these keys are kept at different places.
Whether people actually check the keys they import is up to them, but we
shouldn't say that we wouldn't do it just because the assumed majority
of people wouldn't check it.
> How many people would fall for a fake e-mail from Sopwith announcing
> the new Fedora Rawhide automated-build signing key, with instructions
> on how to install it such that up2date will use it. Instructions that
> could also get up2date or yum to use a mirror known to have been
> broken into.
I think that this should compel us all to use signatures for anything
where it is important that people can verify "who wrote this". When
issuing announcements I used to sign them with my key, but ceased to do
it because of the hassle when I wrote the email on a remote system while
I have the key only locally (i.e. on a USB stick). I'm regularly
thinking about how to avoid this without compromising the security of
the key, but to no avail yet.
> Getting people to trust such mirror site isn't Red Hat's fault either,
> but it's something Red Hat could help avoid by signing all packages,
> yes. Unfortunately such signing is not practical, and gets in the way
> of the real goal of rawhide (which, as you know by now, is to get a
> backdoor into everybody's machines: any Red Hat developer can build a
> package that makes to rawhide and, next day, he'll have an army of
> zombies ready to launch his DoS attack against www.mycrosoft.com. Too
> bad there's a typo in the site name ;-)
That is the same for non-Rawhide packages ;-).
> Just to make it clear, I don't speak for Red Hat, and I'm totally
> unfamiliar with the procedure Red Hat uses to sign packages. I'm just
> working on assumptions driven from some knowledge on good security
> practices, and a bit of common sense. I thought it would be important
> to make this clear, before it hits Slashdot. Not that the average
> Slashdot reader would pay attention to this fine point :-)
ACK. I am I and Red Hat is Red Hat (and the network is the network and
the computer is the computer, sorry for the confusion) for the purposes
of this email ;-).
Nils Philippsen / Red Hat / nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
More information about the test