On 10/10/14 8:07 PM, Jeremy T. Bouse wrote:
> Granted I haven't completed taking a good look at the code yet, but to
> address Felix's concerns. What about a method of caching successful (ie:
> non-vulnerable) CVE fact results for an administratively configured
> time? This could limit the number of facts that have to run through
> their logic to verify on each run but also allow the administrator to
> configure this cache to expire at some point in time to re-validate
> everything to ensure a regression hasn't occurred.
>
> I do agree with Garrett that a common framework to identify these
> vulnerabilities and be able to respond quickly is both needed and a very
> valuable framework to have in place. Fits nicely with being able to use
> your run reports for auditing and with PuppetDB very easy to query and
> determine risk assessment of your environment quickly.
>
> On 10/10/2014 07:23 PM, Felix Frank wrote:
>> Hi Garrett,
>>
>> cool idea. I think it could use a dial to explicitly whitelist the facts
>> that I want to be populated. Deploying an ever growing range of
>> (sometimes expensive) checks to all agents, all of which will forever
>> return false after patching, is not a merry perspective.
>>
>> What do you think?
>>
>> Cheers,
>> Felix
>>
>> On 10/10/2014 11:46 PM, Garrett Honeycutt wrote:
>>> Hello,
>>>
>>> Published puppet-module-cve[1] to act as a framework for adding facts
>>> for specific CVE's that tell you if you are vulnerable to them.
>>>
>>> Inspiration came after ShellShock where I saw people had written modules
>>> with corresponding facts exclusively for that exploit. Our community
>>> needs a simple module that is easily extended to test for multiple CVE's
>>> instead of managing a bunch of separate modules that each check for one
>>> exploit.
>>>
>>> Each CVE has its own flat fact, such as 'cve_2014_6271'.
>>>
>>> $ facter -p cve_2014_6271
>>> not_vulnerable
>>>
>>> There is a structured fact, 'cve', that returns a list of all tested
>>> CVE's, all vulnerable CVE's, and all CVE's to which you are not vulnerable.
>>>
>>> $ facter -p --yaml cve
>>> ---
>>> cve:
>>> vulnerable:
>>> - cve_666
>>> tested:
>>> - cve_777
>>> - cve_2014_6271
>>> - cve_666
>>> not_vulnerable:
>>> - cve_777
>>> - cve_2014_6271
>>>
>>> By default the module is quiet, though you can enable the ability to use
>>> notify{} to alert you to which CVE's you are vulnerable.
>>>
>>> Looking forward to your help in adding facts to check for more exploits.
>>>
>>> [1] - https://github.com/ghoneycutt/puppet-module-cve
>>>
>>> Best regards,
>>> -g
>>>
>>
>
>
Hi Jeremy,
Thanks for taking a look at this project. As far as I can tell, Facter
does not currently support any caching mechanism between Facter runs.
This could be worked around by adding that logic to these facts in
different ways, such as creating files and checking for their mtime,
though this sounds like a lot of over engineering to me and would make
the checks overly complex.
I believe that the blacklist solves your use case, since you can disable
facts through that mechanism and if you want to check them again, you
either modify Hiera and do a Puppet run or just delete the files to the
corresponding CVE's from the blacklist directory.
Best regards,
-g
--
Garrett Honeycutt
@learnpuppet
Puppet Training with LearnPuppet.com
Mobile: +1.206.414.8658
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5438813C.2070700%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.
