On 10/10/14 7: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 Felix,
I was thinking of that though my approach was to use a blacklist to
disable specific facts. That way we go with least surprise so that the
default would be to check for everything if you include the class.
Hopefully folks would only blacklist expensive facts that they are
confident in and not all cve facts after they patch, as the exploit
could reappear in their environment.
To that end, I could create a define that you pass the checks to
blacklist which could be defined in Hiera. On the first puppet run, all
facts would be synced and executed, then puppet would blacklist whatever
you defined, and then on subsequent runs the facts would be skipped.
Something like this in Hiera
cve::blacklisted:
- cve_666
- cve_777
We could check if a file exists in a directory and if so, skip the fact.
Suggest using /usr/local/etc/cve/<fact_name>
What do you think?
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/54387847.4050407%40garretthoneycutt.com.
For more options, visit https://groups.google.com/d/optout.
