From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 25 15:39:48 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 977A4187; Sun, 25 Aug 2013 15:39:48 +0000 (UTC) (envelope-from royce.williams@gmail.com) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C4A6923D9; Sun, 25 Aug 2013 15:39:47 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id r12so814329lbi.27 for ; Sun, 25 Aug 2013 08:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=cL7OmDXF0/rjXmrfQtGy+6CuHcAOznrGhTf/I7nmtwc=; b=l2Nm6HrtLCTOqmY3m3EoF2mzpI+aJ3tKJBK5jj9E5BAcY1BZvYTgnUM62g+0KimBON 6eLMcewaFjSiP7uukx9HvmxVqYO9I+TwQmX3GbjibkqacpLNUeOpJyLmucqmr64WFCsV R0co+Ams3HirN8HEnOlsl9AYs1UCUHcwoHuPnVguFWKwuofamimRcKXHsvZdzUHKsxor wXPNb5rYNI0oE6gr8zrlCKOQPFqdICGnjqGv6d2RntXA8MX2dYuqHzWShdz1FCyLEdmO HzjsCfYUKl76/PijJEl5cSXBTy1Xok2sc4cz7js8ka/il//FSRaz4NXkKvGvh07osVO2 mFbA== X-Received: by 10.152.2.226 with SMTP id 2mr9364183lax.14.1377445185590; Sun, 25 Aug 2013 08:39:45 -0700 (PDT) MIME-Version: 1.0 Sender: royce.williams@gmail.com Received: by 10.112.138.227 with HTTP; Sun, 25 Aug 2013 08:39:25 -0700 (PDT) In-Reply-To: <20130825110520.GJ24767@caravan.chchile.org> References: <20130822204958.GC24767@caravan.chchile.org> <5217AD9E.1000100@bluerosetech.com> <20130824165704.GD24767@caravan.chchile.org> <20130825110520.GJ24767@caravan.chchile.org> From: Royce Williams Date: Sun, 25 Aug 2013 07:39:25 -0800 X-Google-Sender-Auth: 9wo9CrTGzKoa9p0crTn9116LJxc Message-ID: Subject: Re: weekly periodic security status To: FreeBSD Hackers , Jeremie Le Hen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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 15:39:48 -0000 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. Royce