auto importing rpm gpg public keys from keyserver

[Jeff Johnson]

On Jun 15, 2006, at 4:11 PM, Andrea Arcangeli wrote:

> 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.
>

A, within python. Yes, likely i18n xgettext extraction.

>> I'm much happier w/o tghe popen ...
>
> Ok. The only popens left are for gpg communications.
>

The real problem is the utter lack of reasonable python gpg bindings.
The only bindings I'm aware of are popen based ...

>> 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.
>

Ah, sounds like giving up the ability to do most syscalls. I'll take  
a look.

Still, rpm is used on non-linux too, so marrying *.rpm reads to some  
exotic
linux functionality is perhaps unattainable. My current thoughts are  
to use
xml or yaml as an import/export markup within *.rpm packages. The markup
parser is easier to retrofit sanity checks upon than binary integers  
in arrays,
and the markup parse isn't necessarily much slower than the byte  
swapping
and string skipping currently done by headerLoad().

> 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).
>

Well if write(2) is still enabled ... but I'll take a look, thanks  
for the ptr.

>> 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.
>

grep vsflags /usr/lib/rpm/macros

I've been asked to implement a globally enforcing mandatory pkg  
verification
policy in rpm several times.

>> 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.

Turning ts.setVSFlags() into a noop is the only way I can think of to  
achieve "mandatory".

73 de Jeff