Date: Sun, 25 Aug 2013 07:39:25 -0800 From: Royce Williams <royce@tycho.org> To: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Jeremie Le Hen <jlh@freebsd.org> Subject: Re: weekly periodic security status Message-ID: <CA%2BE3k93Dmoi9XzyTygcL=TTZSa0XbMOC55KjrBJL%2Bb4omGhMuA@mail.gmail.com> In-Reply-To: <20130825110520.GJ24767@caravan.chchile.org> References: <20130822204958.GC24767@caravan.chchile.org> <5217AD9E.1000100@bluerosetech.com> <CA%2BE3k910-BqOdDtA9sWTxVuKxtJSS02w4PSeTmM%2BJxPqNQ5Jyw@mail.gmail.com> <20130824165704.GD24767@caravan.chchile.org> <20130825110520.GJ24767@caravan.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 25, 2013 at 3:05 AM, Jeremie Le Hen <jlh@freebsd.org> wrote: > On Sat, Aug 24, 2013 at 06:57:04PM +0200, Jeremie Le Hen wrote: > > On Fri, Aug 23, 2013 at 08:35:55PM -0800, Royce Williams wrote: > > > On Fri, Aug 23, 2013 at 10:44 AM, Darren Pilgrim < > > > list_freebsd@bluerosetech.com> wrote: > > > > > > > Thank you for this, but if I may make one suggestion: don't combine > all > > > > the security report settings--keep both daily_* and weekly_*. This > makes > > > > possible running some security tasks on a daily basis and others on a > > > > weekly basis. For example, daily pkg/portaudit checks, but weekly > > > > filesystem scans. > > > > > > > > > > Agreed. I welcome and would use the weekly option at this level of > > > granularity, but would like to retain daily for many checks, and so > would > > > not use weekly if was an all-or-nothing option. > > > > Sounds like a good idea. However I don't know how to implement this > > because, in the current state of the periodic security scripts, there is > > no way to know whether a script had been called from daily or weekly > > periodic scripts, so no way to know which variable to check. > > > > The easy way to work around this would be to declare an environment > > variable from 450.status-security, but it sounds like a hackish way > > because you create an additional dependency for the periodic security > > scripts. > > I've modified periodic(8) to set the $PERIODIC environment variable in > r254829. > > The attached patch does more or less what you requested, but slightly > differently. > > We now have the following variables to control daily/weekly security > runs: > daily_status_security_enable="YES" > daily_status_security_inline="NO" > daily_status_security_output="root" > > weekly_status_security_enable="YES" > weekly_status_security_inline="NO" > weekly_status_security_output="root" > > > And the following variables to control whether you want each check to > run "daily", "weekly" or directly from "crontab" (the default, backward > compatible values are shown): > security_status_chksetuid_enable="daily" > security_status_neggrpperm_enable="daily" > security_status_chkmounts_enable="daily" > security_status_chkuid0_enable="daily" > security_status_passwdless_enable="daily" > security_status_logincheck_enable="daily" > security_status_chkportsum_enable="NO" > security_status_ipfwdenied_enable="daily" > security_status_ipfdenied_enable="daily" > security_status_pfdenied_enable="daily" > security_status_ipfwlimit_enable="daily" > security_status_ipf6denied_enable="daily" > security_status_kernelmsg_enable="daily" > security_status_loginfail_enable="daily" > security_status_tcpwrap_enable="daily" > > > The periodic.conf(5) manpage and default/periodic.conf have been > updated accordingly, but I plan to further rework them after the patch > is committed (especially, grouping security related variable into their > own section). That way the modification done by the patch remain clear. > > Patch available here: > http://people.freebsd.org/~jlh/daily_or_weekly_status_security.diff > > This approach creates the granularity that I was looking for, and represents a non-trivial amount of work; thanks for taking this on! I haven't looked closely at the patch, but I do have a couple of style comments. If someone uses an unrecognized value the config, the phrase "this is incorrect", while strictly accurate, is a little harsh (and less FreeBSD-ish, I think). I would expect something more along the lines of "Valid values are now (daily|weekly|NO). See periodic.conf(5) for more details." This gives the user the minimum information, leaves breadcrumbs ... and is a little less potentially pejorative. :-) Also, while I see the utility in toggling daily/weekly in the *_enable variables, how much precedent is there for overloading *_enable in this way? It's the first time that I've seen it, and may be a mild POLA violation. Most scripts seem to use *_enable solely as a binary YES/NO toggle, and then modify script behavior with other variables (perhaps "_period" in this case?) That would double the config size, though, so I definitely see why you went this route. Both of the above are closely related. If the period was stored in a different variable, and the default _period was "daily", then the vast majority of the user base would still be "correct" and Just Keep Working ... and only those interested in weekly updates would need to modify anything. Just my $0.04. Royce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BE3k93Dmoi9XzyTygcL=TTZSa0XbMOC55KjrBJL%2Bb4omGhMuA>