From owner-freebsd-security@FreeBSD.ORG Sat Feb 18 21:59:03 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27BCF106566C for ; Sat, 18 Feb 2012 21:59:03 +0000 (UTC) (envelope-from rsimmons0@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id CF62A8FC18 for ; Sat, 18 Feb 2012 21:59:02 +0000 (UTC) Received: by ghbg15 with SMTP id g15so2604589ghb.13 for ; Sat, 18 Feb 2012 13:59:02 -0800 (PST) Received-SPF: pass (google.com: domain of rsimmons0@gmail.com designates 10.101.9.7 as permitted sender) client-ip=10.101.9.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rsimmons0@gmail.com designates 10.101.9.7 as permitted sender) smtp.mail=rsimmons0@gmail.com; dkim=pass header.i=rsimmons0@gmail.com Received: from mr.google.com ([10.101.9.7]) by 10.101.9.7 with SMTP id m7mr6503673ani.7.1329602342210 (num_hops = 1); Sat, 18 Feb 2012 13:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=q7NH3g8SUBycG6XdDji3Ho7b/iebtYQwgQquBhfGcAY=; b=i5aZIr/yMCBaPcA/UqNU1VvWLKR2U8LHpuPSGTyUQEeyosJLt+8ggRvrxUyYmp0QXI Jv0zqSzkX95psZiewwqAfYB5fjPhxDOJLQ/U4hZE8Adg8Gj4W+/teZp6gq6mQI2kbqjj foV0wbXrOYZWLF0ov6KnIxeAyQ7Kk0vxV04dU= MIME-Version: 1.0 Received: by 10.101.9.7 with SMTP id m7mr4978321ani.7.1329600920937; Sat, 18 Feb 2012 13:35:20 -0800 (PST) Received: by 10.101.102.11 with HTTP; Sat, 18 Feb 2012 13:35:20 -0800 (PST) In-Reply-To: <20120217235620.4BEF4106566B@hub.freebsd.org> References: <20120217120034.201EB106574C@hub.freebsd.org> <20120217152400.261AC106564A@hub.freebsd.org> <20120217194851.D76DE1065670@hub.freebsd.org> <4F3EE1C9.4030601@quip.cz> <20120217235620.4BEF4106566B@hub.freebsd.org> Date: Sat, 18 Feb 2012 16:35:20 -0500 Message-ID: From: Robert Simmons To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: periodic security run output gives false positives after 1 year X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2012 21:59:03 -0000 On Fri, Feb 17, 2012 at 6:56 PM, Roger Marquis wrote: > I don't personally recall a time when everything else wasn't logging the > year, in one format or another. =A0That's not to imply that syslogs > shouldn't be distinguishable by year but the question seems to be where > the year should be logged, A) on every line or B) in the archive file > name. There already is a standard, RFC 5424: freebsd-security@freebsd.org You are asking, should we make our own decision to do this totally differently than the standard set in that RFC, or should be implement that RFC? Another option is to do nothing and stick with the way it is. I think the way to proceed would be to implement RFC 5424, and have it as a switch in rc.conf, something like: syslogd_flags=3D"-x" where x is the new switch that would enable RFC5424 style logging. This would be optional for now. Then with FreeBSD 10, 5424 would become the default with the option now being a flag -y to enable old style logging for backwards compatibility. > I suspect it was not common practice to leave logs on the server for more > than a year when Allman originally wrote syslog, and I have not seen an > environment where logs are left in /var/log for over a year. =A0Personall= y, > I would rather see FreeBSD stay backwards compatible and A) leave the > syslog timestamp format alone instead opting for KIS by simply writing > the year in the archive file name rather than wasting 5 bytes on every > line of every syslog log file. =A0YMMV. It really shouldn't be a common practice, but we live in a world where governments are forcing data retention laws. In is an unfortunate reality that needs to be dealt with. http://en.wikipedia.org/wiki/Telecommunications_data_retention Also, I'm not sure I follow the logic behind some of the people on this list saying not to implement this at all. It should be an option for now, then the default on the other side of a major OS version with the old way then available as an option. This seems the most rational path to take.