FWIW, here's what I did in a previous environment: I have a script that is run by cron once a day (in the wee, small hours) that scans for all SUID/GUID files and compares them to a list of allowed SUID/GUID kept with the script. The script and the list are maintained by puppet.
The output of the script is a custom fact that reports unauthorized SUID/GUID files through Puppet.
From that Puppet report, admins either remove the offending file(s), change their permissions, or add it to the allowed list in Puppet for that server.
One additional note: In this environment, Puppet agent was not left running as a daemon. It was run once a day by cron. The other scripts were scheduled to run an hour or so before the Puppet cron was to run. YMMV HTH “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin & Hobbes) On Sep 08, 2015, at 08:50 AM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote: Just out of curiosity, what's the benefit of making this a fact? I'm thinking that this would be better relegated to a monitoring system, not a configuration management system. (Yes, you can use Puppet as a monitoring system but that's not really what it is designed for and you'll end up slowing everything down over time.) Thanks, Trevor On Tue, Sep 8, 2015 at 12:15 AM, Corey Osman <co...@logicminds.biz> wrote: As Trevor mentioned above this is something you want to control externally via cron and not puppet. I took a slightly different approach and used an external fact which allowed be to write a fact in bash. There is no reason why you couldn't do this in a Ruby based fact but since all the original code was written in bash I used external facts simply to save time. https://gist.github.com/logicminds/2389d980f00333dcb48d The key item is that this fact alone takes 37 seconds to run so I decided to cache the result for 12 hours which obviously speeds up fact values retrieval. I wasn't crazy about having a bunch of random cron jobs to cache the value of 10+ facts so I built the control mechanism into the fact code itself so that it doesn't rely on cron or some other service. Hit me up privately as I might have more code to share that could be useful to you. Corey On Sunday, September 6, 2015 at 7:22:28 AM UTC-7, Trevor Vaughan wrote: This rule will let you know when an SUID binary is *executed* https://github.com/simp/pupmod-simp-auditd/blob/master/templates/base.erb#L50:L55. I would not run any filesystem searches from Puppet, I would relegate those to cron+syslog so that you can better control the amount of I/O churn on your system over time. Thanks, Trevor On Fri, Sep 4, 2015 at 2:54 PM, Sean <smal...@gmail.com> wrote: Hi, I'm using a module from the Forge to manage auditd rules, the module works quite well and managing rules is very easy. The hard part is that there's a requirement to audit use SUID files on each system. With out knowing exactly what files are SUID on every server in the field, since there are several linux flavors and versions, I'm finding myself thinking the only way to accomplish this is to write a custom fact to hold all the SUID files as an array, then pass the array to the resource creator. I just don't relish the idea of running a find command from / every 30 minutes. Might anyone have any better ideas? Thank you kindly! -- 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...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e848e8ab-0a96-4934-9382-42f3b828d529%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- 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/b3f67609-2abb-431d-bd77-29860fc909ea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVKSM3UzYQYNv92UbfxtAW3rJVUP4V10yW_Yg795GoAPQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- 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/dfdce095-71bf-470a-841b-e847c2416a7a%40me.com. For more options, visit https://groups.google.com/d/optout.
