[PATCH] Add support for zipfile creation

Martin Preisler mpreisle at redhat.com
Thu Mar 14 15:02:32 UTC 2013


Hi,

[snip]
> I do not subscribe to the theory that remote fetches are a potential
> risk. I will be happy to defend this carefree attitude vigorously
> and at length.

This is far worse than a potential risk, DNS poisoning is not just theoretical ;-). All it takes is a one line change of /etc/hosts either on the DNS server that is used locally or even on the machine. Or setting up a transparent reverse-proxy somewhere in the chain between you and the content provider. Then all compliance checks can pass forever and ever without anyone noticing.

It also creates a single point of failure. What if someone takes over the domain that is used to fetch the files? What if the hosting provider is hacked? Do you think it's impossible for NIST to have any of these problems? [1]

> Even if one warrants that remote fetches offer some risks, these
> could be obviated by providing a mode of operation for those who
> fear them, as has already been done for href attributes, and an
> obverse mode for those who embrace them.

I would dare say that people who do not fear those risks shouldn't be in this business. After all you are doing security compliance checking. If you are happy to enable external factors (your ISP, hosting provider, ...) to affect your results it makes no sense to even check.

It can also expose information about your internal infrastructure to the outside.

> I will also (at the risk of citing a document for which I have grave
> misgivings) mention that NIST SP 800-126r2 ยง3.10 provides a method
> by which document integrity can be assured. Please do not read any
> other part of that publication. Prefer the prior version for now.

We are aware of this and efforts have been made to make this work. Unfortunately it gets very complicated very quickly. There are countless ways to sign the content and there are countless ways to check. For now we recommend this: https://www.redhat.com/archives/open-scap-list/2012-December/msg00000.html

Although I do admit that I would prefer to have this in openscap itself and always enabled.

[1] http://www.theregister.co.uk/2013/03/14/us_malware_catalogue_hacked/

-- 
Martin Preisler


More information about the scap-security-guide mailing list