From owner-freebsd-security@FreeBSD.ORG Fri Aug 24 13:02:22 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2FE40106564A for ; Fri, 24 Aug 2012 13:02:22 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id C72B88FC12 for ; Fri, 24 Aug 2012 13:02:21 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 17B932F2B for ; Fri, 24 Aug 2012 12:52:59 +0000 (UTC) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by conversation.bsdunix.ch (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rCNjNx0FXyUF for ; Fri, 24 Aug 2012 12:52:58 +0000 (UTC) Received: from toms-mac.home (177-185.107-92.cust.bluewin.ch [92.107.185.177]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTPSA id 498392F28 for ; Fri, 24 Aug 2012 12:52:58 +0000 (UTC) Message-ID: <50377929.3060106@bsdunix.ch> Date: Fri, 24 Aug 2012 14:52:57 +0200 From: Thomas User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443> <20120819144637.GA17778@psconsult.nl> In-Reply-To: <20120819144637.GA17778@psconsult.nl> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: getting the running patch level 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: Fri, 24 Aug 2012 13:02:22 -0000 On 8/19/12 4:46 PM, Paul Schenkeveld wrote: > On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote: > > Having read all responses so far I think a summary of the issue at hand > is: > > - Uname only reports on the kernel version, currently we do not store > nor report the userland version. > > - People would love to know what version of FreeBSD, both kernel and > userland, is currently installed/running. > > - Userland can either be upgraded using make {build,install}world or > by freebsd-update, neither logs the version to which userland was > updated. > > - Reporting the userland version is not trivial as not necessarily all > parts of userland are of the same version, especially after doing > an buildworld/instrallworld with a changed src.conf or make.conf. > > - We currently reflect the last booted kernel version in /etc/motd. > > My suggestion would be: > > - Teach both installworld and freebsd-update to maintain manifest > files of what is installed and log that update, place all manifests > somewhere under /var/db and the update log in /var/log. > > - If the above log message is well defined and includes the method > by which the update was done, it can be parsed by /etc/rc.d/motd > and we could extend the information in /etc/motd to also include > information about userland. Something like: > > > portupgrade 2012-08-19T16:26:41 paul 8.3-RELEASE-p4 > installworld 2012-08-19T16:31:36 paul 8-STABLE-r231558 > > - Having manifests of what's installed, one could check if all files > are stil the right version, if older manifests are not discarded > when performing an update this could also detect files that were > not updated for whatever reason or that were reverted, i.e. by > restoring some backup. E.g.: > > Current userland version: 8.3-RELEASE-p4 > /usr/sbin/named is at 8.3-RELEASE-p2 > /usr/bin/openssl is at 8.3-RELEASE > > - Such a time-consuming check could be run from periodic (weekly or > monthly perhapd) and be a valuable tool to warn sysadmins of files > not being what they should be. > > - Adding, in the case of freebsd-update, a signature to the manifest > files that can be checked against the signature in the freebsd-update > master repository could turn this tool into something of a integrity > checking tool. > Sounds good if you have a just a few systems. In a large environment, snmp is quite common to collect release information. AFAIK snmp uses kern.version and kern.osrelease for this.This sysctls are read only. Any ideas how this issue can be fixed for snmp in a easy way? Regards, Thomas