Date: Sun, 25 Aug 2013 22:03:58 +0200 From: Jeremie Le Hen <jlh@FreeBSD.org> To: Royce Williams <royce@tycho.org> Cc: Jeremie Le Hen <jlh@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: weekly periodic security status Message-ID: <20130825200358.GL24767@caravan.chchile.org> In-Reply-To: <CA%2BE3k93Dmoi9XzyTygcL=TTZSa0XbMOC55KjrBJL%2Bb4omGhMuA@mail.gmail.com> 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> <CA%2BE3k93Dmoi9XzyTygcL=TTZSa0XbMOC55KjrBJL%2Bb4omGhMuA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Aug 25, 2013 at 07:39:25AM -0800, Royce Williams wrote: > 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. It's more than that, I really like your proposal. I've implemented it here: http://people.freebsd.org/~jlh/security_status_period.diff -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130825200358.GL24767>