auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 15, 2006, at 3:42 PM, Andrea Arcangeli wrote:

>
> If the userid data and the fingerprint of the key (both shown in the
> popup window) are both correct, it's secure enough to trust the  
> key. The
> key will be injected into rpm keyring and then it's up to RPM to check
> the signature of the payload, and not just that the keyid of the
> public-key matches the keyid of the rpm package. I assume rpm does the
> right thing here (if it's slower like you said in previous email, rpm
> must be checking the signature for real and not just comparing the  
> keyid).
>

rpm itself uses only the fingerprint everywhere except the string you  
just extracted.

I'm in the process of adding Public subkeys ro rpm this week, that  
delegation must be explicitly
verified, hence my otherwise random aside.

>> Yes, create a new transaction, set VSFlags as appropriate.
>>
>> The real issue is that signature checking policy needs to be set
>> outside of
>> applications. Say smart chooses to verify signatures, yum does  
>> not, and
>> both are used to install software on the same box.
>
> YAST2 in suse 10.0 and all previous always did signature checking too,
> but yet smart didn't by default, what's the difference?
>
> We can't fix all package managers in the world, we're in smart list,
> otherwise you should also plan how to fix zen/rug in 10.1 that had  
> more
> serious problems than the signature checking.
>
>> The policy of whether to verify signatures or not needs to be per-
>> system, not per-application, at least in some ideal world.
>
> In the ideal world, it can't be in rpm business to set the policy
> because the same mechanism should work for deb too. Infact in the  
> ideal
> world you could use rpm and deb in the same system trasparently.
>

rpm is not trying to set policy, only provide a universally useful  
mechanism. If applications
like yum choose to clobber what the user specifies in rpm  
configuration, all I
can do is shame developers publically.

>> Yes, there's a number of alternatives to address the design  
>> deficiencies
>> in rpm signatures.
>>
>> The simplest answer is to sign *.rpm files with onepass signatures
>> using gpg and whatever functionality one wants.
>>
>> I like that answer because I don't have to change 1 line of rpm  
>> code ;-)
>
> So is rpm already exploitable or not? I hope not. But if not, how  
> do you
> know that gpg is less probable to be buggy in the signature checking
> code than rpm? I don't really see a big risk difference in invoking  
> gpg
> or rpm first on maliciously altered data: the only important thing  
> would
> be to do this first invocation as user nobody to handle obviously
> corrupt packages that may segfaults. I would use a new ts after fork
> and change of uid for that check, but it will be slower since it'll  
> have
> to parse the header and check the singature multiple times.


I know of no exploits through twisted rpm packaging in rpm-4.1 and  
later.
In fact, I know of no current rpm exploits, but rpm-3.0.x and  
rpm-4.0.x were *designed*
to segfault when something was wrong, so ... caveat emptor!

However, the rpm code paths are far more complicated than I would  
like (my vote
for 1pass signatures everywhere), and there are insufficient sanity  
checks on the
data contained within headers because of poor design originally. Who  
knew?

Repeated requests for an audit of rpm, on vendor-sec, and at RH, over  
the past 3 years
have been met with deafening silence because of the complexity of the  
code
paths. So much for the wonderful efficiency of OSS development.

Have at an audit, I'm more than willing to remedy any problem that is  
found.

OTOH, intertwining signature verification with package header reading  
avoids races,
and bait-and-switch, type exploits that are possible if a *.rpm is  
verified outside of rpm.

If the rpmlib API is used correctly, rpm will verify header metadata  
before use wherever
and whenever needed. That was my intent, and I believe I've  
succeeded. Note that there
are still routines in rpmlib's API to read headers The Good Old Way w/ 
o verifying signatures/digests,
and there's lots of rpm-3.0.x packaging around w/o header-only  
digests and signatures.

But its your security at risk, by all means, use chroot's and  
"nobody" and whatever
else you need to feel secure.

And gpg and rpm are prolly equally prone to failure through exploits.  
rpm installs -- because run as root --
are perhaps a more attractive venue than gpg exploits.

73 de Jeff