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:
1. 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)
2. 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 <[email protected]> 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 --
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
