Date: Sun, 25 Aug 2013 15:24:39 -0500 From: James Gosnell <jamesgosnell@gmail.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: weekly periodic security status Message-ID: <CAEhBLvgcw4eziQdwKGO9bv=nFH2eTk04_1_=MHVKm8O_pzvX=g@mail.gmail.com> In-Reply-To: <20130825200358.GL24767@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> <CA%2BE3k93Dmoi9XzyTygcL=TTZSa0XbMOC55KjrBJL%2Bb4omGhMuA@mail.gmail.com> <20130825200358.GL24767@caravan.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
*Throughout the land, hard drives rejoice* On Sun, Aug 25, 2013 at 3:03 PM, Jeremie Le Hen <jlh@freebsd.org> wrote: > 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > -- James Gosnell, ACP
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAEhBLvgcw4eziQdwKGO9bv=nFH2eTk04_1_=MHVKm8O_pzvX=g>