On Monday, November 13, 2017 12:46:53 PM EST Trevor Vaughan wrote: > Hi All, > > I've been re-roaming through the SSG and this is probably the first of a > many part thread regarding different checks. > > TL;DR; The potential risk caused by enabling 'repo_gpgcheck' outweighs any > potential benefit if TLS is enabled.
I'm not sure that I agree with this assessment. I am going to look into this in more detail over the next couple of days because...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. So, if there is anything amiss, I'd be inclined to file bz to get it fixed. Using TLS defends against a different attack vector than the one repo_gpgcheck and gpgcheck were designed for. So...I'll get back to everyone with what I find out. -Steve > In my opinion, the following check should *only* be enabled if all of your > repositories are internally managed > xccdf_org.ssgproject.content_rule_ensure_gpgcheck_repo_metadata. > > The reason for this is that YUM presently does not (to my knowledge) have > any way to differentiate between package signing GPG keys and repo signing > GPG keys. > > This means that if, for instance, I host my packages via some shared Nexus, > then I have to add the Nexus GPG key to my trust list for the repo. > > I fundamentally do *not* want to do this! I shouldn't be allowing my Nexus > maintainer to potentially install software on my system without my explicit > knowledge. > > You should use TLS, and the repo should have a trusted certificate there > and that should be sufficient for the metadata until RPM can tell the > difference between these two certificates. > > Please let me know if I've missed something, but I don't remember seeing > options to split out the two sets of certs. > > Additionally, this is marked as 'high' severity and that seems to be > massive overkill considering that 1) the packages are still signed and > validated and 2) TLS is required. _______________________________________________ scap-security-guide mailing list -- [email protected] To unsubscribe send an email to [email protected]
