From owner-freebsd-security@FreeBSD.ORG Mon Aug 20 13:59:04 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 3A40F1065672 for ; Mon, 20 Aug 2012 13:59:04 +0000 (UTC) (envelope-from paul@psconsult.nl) Received: from mx1.psconsult.nl (unknown [IPv6:2001:7b8:30f:e0::5059:ee8a]) by mx1.freebsd.org (Postfix) with ESMTP id 7C5B78FC17 for ; Mon, 20 Aug 2012 13:59:03 +0000 (UTC) Received: from mx1.psconsult.nl (mx1.hvnu.psconsult.nl [46.44.189.154]) by mx1.psconsult.nl (8.14.5/8.14.4) with ESMTP id q7KDwvTA004138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 20 Aug 2012 15:59:02 +0200 (CEST) (envelope-from paul@psconsult.nl) Received: (from paul@localhost) by mx1.psconsult.nl (8.14.5/8.14.4/Submit) id q7KDwvKk004137 for freebsd-security@freebsd.org; Mon, 20 Aug 2012 15:58:57 +0200 (CEST) (envelope-from paul@psconsult.nl) X-Authentication-Warning: mx1.psconsult.nl: paul set sender to paul@psconsult.nl using -f Resent-From: Paul Schenkeveld Resent-Date: Mon, 20 Aug 2012 15:58:57 +0200 Resent-Message-ID: <20120820135857.GA4051@psconsult.nl> Resent-To: freebsd-security@freebsd.org Date: Sun, 19 Aug 2012 16:46:37 +0200 From: Paul Schenkeveld To: freebsd-security@freebsd.org Message-ID: <20120819144637.GA17778@psconsult.nl> References: <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443> User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 20 Aug 2012 13:59:04 -0000 On Thu, Aug 09, 2012 at 11:44:02AM +0200, Roberto wrote: > > Hi all, > I would like to know if there is a command or a way to retrieve the "patch > level" (the handbook defines it "builds names" like 7.0-RELEASE-p1) of the > running system: just an example, if I run: > > # freebsd-update fetch > ... > No updates needed to update system to 9.0-RELEASE-p4 > > > or: > ... > The following files will be updated as part of updating to 9.0-RELEASE-p4: > ... > > but this give me no info about the current system; I tried a brief search in > config file but no luck; > > again the question is: > is there a way to determine for a running server which "patch level" is > currently at ? 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. Having installworld produce a manifest may seem like a big change to the current build infrastructure but in some other thread I read about people working towards installworld being run as a normal user and producing mtree like files that can be used in combination with makefs to make installables as a normal user. I think that whatever comes out of that project can serve as [a starting point for] these manifest files. The /etc/issue file mentioned several times in this thread is like motd but intended to be shown before a login prompt. This works for console logins (getty) but not for remote logins. The mechanism of /etc/rc.d/motd could of course be used for /etc/issue too but personally I'd rather see all version info, kernel and userland, reported in the same place: motd. My 2 cents. With kind regards, Paul Schenkeveld