weekly periodic security status

[James Gosnell]

*Throughout the land, hard drives rejoice*


On Sun, Aug 25, 2013 at 3:03 PM, Jeremie Le Hen <jlh at 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 at 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 at 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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>



-- 
James Gosnell, ACP