Steve,

I get the bigger value of the GPG validation check but I think that the current implementation is severely flawed.

If there were a separate setting for GPG keys used for repo validation, such as repo_gpgkey, I would be more than happy to use it and flip it on. However, currently, these are the two potential threat avenues:

Accept GPG Keys for Repos

Allows *repository maintainer* (Nexus, PackageCloud, random directory on a webserver) to transparently add or replace arbitrary vendor packages with those of their choosing targeted for thousands of systems without the downstream user knowledge

Mitigation: Manually validate all package signatures on your system after installing them (Horrible)
Mitigation: Require internal YUM mirrors of all upstream packages to a trusted repository via the SSG (I'm kind of OK with this one, but how do you check it? Also, the fundamental issue still holds unless you're resigning the repodata and, if this is automated, a system compromise is just as bad, if not worse, than the TLS case since arbitrary things could be signed)

Trust TLS

In the event of a repository system compromise, bypassing SELinux restrictions and DAC permissions (kernel level exploit?) someone can remove flawed package and regenerate the metadata

Mitigation: Run the vendor OVAL for checking insecure packages (which we're all doing anyway, right?!)

Unless I'm missing something, I know which one I'm much more comfortable with latter as something that is better for the user and easy to mitigate using currently mandated best practice.

Again, once something like repo_gpgkey exists and is fully integrated, I'd be more than comfortable with this.

Thanks,

Trevor

On Tue, Nov 14, 2017 at 9:47 AM, Steve Grubb <sgrubb@redhat.com> wrote:

On Tuesday, November 14, 2017 9:37:18 AM EST Arnold, Paul C CTR USARMY PEO
STRI (US) wrote:
> On 11/13/2017 06:59 PM, Steve Grubb wrote:
> > ...the current rev of OSPP
> > calls out for auditing of software update integrity checks. It calls out
> > for integrity checks and for them to be enabled. It calls out for the
> > vendor to supply SCAP content for the evaluated configuration. So that
> > means we shouldn't be turning it off.
>
> What are we gaining by enabling repo_gpgcheck in addition to gpgcheck?

It's for checking that the metadata hasn't been tampered with since signing.
For example, suppose you need some packages out of EPEL. EPEL has a
distributed mirror list that volunteers contribute bandwidth for everyone's
benefit. However, what if their server became compromised and an attacker
removed the entry for a critical package update for a network facing daemon?
The intent being to keep people from patching to allow more compromises.

This setting would check the metadata to ensure that the signature
verification shows the metadata is untampered with. TLS protects against
modifying an in-transit package or metadata. But it doesn't tell you that your
package resolution is using trustworthy data.

-Steve

Trevor Vaughan
Vice President, Onyx Point, Inc

(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --