From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 25 20:04:01 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D93A1CA4; Sun, 25 Aug 2013 20:04:01 +0000 (UTC) (envelope-from jlh@FreeBSD.org) Received: from caravan.chchile.org (caravan.chchile.org [178.32.125.136]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 48F4D2FA7; Sun, 25 Aug 2013 20:04:00 +0000 (UTC) Received: by caravan.chchile.org (Postfix, from userid 1000) id C193EC1BD8; Sun, 25 Aug 2013 20:03:58 +0000 (UTC) Date: Sun, 25 Aug 2013 22:03:58 +0200 From: Jeremie Le Hen To: Royce Williams Subject: Re: weekly periodic security status Message-ID: <20130825200358.GL24767@caravan.chchile.org> Mail-Followup-To: Royce Williams , FreeBSD Hackers References: <20130822204958.GC24767@caravan.chchile.org> <5217AD9E.1000100@bluerosetech.com> <20130824165704.GD24767@caravan.chchile.org> <20130825110520.GJ24767@caravan.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Jeremie Le Hen , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Aug 2013 20:04:01 -0000 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 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.