From owner-freebsd-security@FreeBSD.ORG Fri Aug 24 15:49:24 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 2441E106566C for ; Fri, 24 Aug 2012 15:49:24 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id D45078FC0A for ; Fri, 24 Aug 2012 15:49:23 +0000 (UTC) Received: by obbun3 with SMTP id un3so5892917obb.13 for ; Fri, 24 Aug 2012 08:49:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=z88mBRI0se+X1jtPphJVlaWDtjkRDpRMQyYCwvJNhvk=; b=amszVt/KT3MN3Ee6FxJ0KPb+lMlNs3zbeKVsxvJyxXxClUoWNeh/pyVg4VwDEhn2Vf DEnsIgmzT+32vEpUZZjSgBJbxCNUzBdUcV+IrfD9XbW7CpV6N4L4G1wYuHD+dUfsjBEx tgSacTtXzRbioguFVUyABjXZrkCHs8Y0OchWI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=z88mBRI0se+X1jtPphJVlaWDtjkRDpRMQyYCwvJNhvk=; b=fRYWxsEAlK+ezCSWJb1sGn7CYvjR+supAvqHBguiSnySgoyKsQA9jKaM8839WWPRZs /KchlFoltbfxXcJaC1LGOh+/z/mTmDWIIGc/xxodsSigvFNc36zhZEltRJTKFaTcQkOD EGJcRQA0ufFx2WfkVbJGB19pSDOsmrcX3SZdT+paXY08meUp1fHe0Cqn8M32dTXVbx6I wbV5ABiV9zX2Vqd3JLC7Xplj6SZW1TuvCRv8/RWlxN4Z/4IeHTCZmua/5BZuJwf+iHw5 7eqnghKm7CNgTmlzMFogf7dIjU11CxLFieIgiU0VYYNlMhwAJL/qLHdV7JlYcpllC2hA Ke9w== MIME-Version: 1.0 Received: by 10.182.76.137 with SMTP id k9mr4243696obw.90.1345823362113; Fri, 24 Aug 2012 08:49:22 -0700 (PDT) Received: by 10.76.85.135 with HTTP; Fri, 24 Aug 2012 08:49:22 -0700 (PDT) X-Originating-IP: [2620:0:1040:201:9db5:5be0:5543:2221] In-Reply-To: <50377929.3060106@bsdunix.ch> References: <20120819144637.GA17778@psconsult.nl> <50377929.3060106@bsdunix.ch> Date: Fri, 24 Aug 2012 16:49:22 +0100 Message-ID: From: "Simon L. B. Nielsen" To: Thomas Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQlvRTTib7gz9Tu0NO6X+l80EC5C2iEsOItX6Kh2THhbOw7MWN4IMSGfXEFjS/5djqoJUjkc Cc: freebsd-security@freebsd.org 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 15:49:24 -0000 On Fri, Aug 24, 2012 at 1:52 PM, Thomas wrote: > 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? Make the snmp daemon not do it that way and support magic new scheme which we will hopefully come up with? -- Simon L. B. Nielsen