auto importing rpm gpg public keys from keyserver

Andrea Arcangeli andrea at suse.de
Thu Jun 15 13:11:03 PDT 2006


On Thu, Jun 15, 2006 at 03:33:51PM -0400, Jeff Johnson wrote:
> Hmmm, which underscore? Likelier a typo bug than translations ...

I see code like this:

            lines.append(_("Will ask RPM to order it."))
            iface.error("\n".join(lines))

I assumed the _ had something to do with translator.

> I'm much happier w/o tghe popen ...

Ok. The only popens left are for gpg communications.

> The parser in rpm-4.1 was tested by exhaustively mangling a header
> with all possible changes, fixing every segfault. The parser has  
> changed little
> since then, but ...
> 
> The risk of exploit is one of design. rpm was *supposed* to segfault on
> damaged data. That, was a much cheerier world than now.
> 
> There has been only one serious BugTraq exploit for rpm, a double  
> free long since
> fixed, not with the OpenPGP parser.

Sounds good then ;) I'm aware there's always the possibility of exploits
while parsing data (see below on my best suggestion on how to make rpm
totally solid, and this is really a rpm business to add the new feature).

The current objective of my patch is that the attacker will need to
first get into the first mirror somehow with a first bug, and later to
exploit a second bug in rpm to get to the home soon-to-be-zombie
computers. If there's no signature check, if he can get to the mirror,
he will get into all computers fetching updates as well immediately
without the need of finding any more bugs. In the meantime that he finds
the second bug, the mirro admin will have a chance to notice. Here two
bugs are better than one ;). It's quite an exponential matter.

> However, the header loading is far more complicated than a simple
> read, and the signatures are inconveniently located in a header.
> Basically,  ts.hdrFromFdno() has an entirely different code path to
> extract the signature from the  overly complicated header container
> before the pkg metadata is read. Once the signature  has been
> extracted from the package, the remaining audit is straightforward, 3
> reads to  get plaintext blob, compute digest, verify signature.

My best suggestion for this, is to look into seccomp to run the
signature check. Current seccomp isn't python/JIT/interpreter friendly
so it really can't be used from smart and you want all rpm users
including the very rpm binary users including the very rpm binary to
take advantage of this.

It's trivial to enable, except that after forking and enabling it, you
will only be allowed to execute the read/write/exit/sigreturn syscalls.

You have to open a pipe with the parent if you want to send the parsed
header payload to it. Or you can only do the signature check in seccomp
mode and re-read from the cache the header in the parent, it's up to
you.

Then if the signature is ok you return 0, and the parent notices all
went well (or you can your own protocol though pipes). This will have
nearly zero slowdown and it doesn't require uid change.

seccomp is unbreakable, more secure than running the first rpm
invocation under xen or anything else, a lot more secure than chroot +
setuid(nobody).

> Make sure that you read the original flags, and then mask on your per-
> application flags, please. That way per-system defaults can be set
> from  configuration even if applications wish to override specific
> behavior. The old value is returned by  ts.setVSFlags() iirc, and
> there is a ts.VSFlags() getter as well. All from memory, holler  and
> I'll actually look at the code, if not. ;-)

You mean that if rpm-check-signature is not set, you want to stick with
rpm defaults? How do you change the rpm defaults btw? I don't know if
they're enabled by default in rpm or not. I thought it was the business
of the package manager to decide if to enable or disable signatures, not
rpm business.

> Otherwise, I shall be forced to make ts.setVSFlags a noop one of  
> these days. I'd rather not do that.

If you don't like the rpm-check-signature option, you should remove it
first, because the *whole* point of that feature is to override rpm
defaults (while providing a default decision if rpm-check-signature is
missing). still it leaves it zero chances for rpm to decide anything
about the signature checking policy. My patch doesn't alter this model,
it only alters the default value.



More information about the Smart mailing list