From owner-freebsd-security@FreeBSD.ORG Fri Aug 10 17:53:58 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 9D1F3106566B for ; Fri, 10 Aug 2012 17:53:58 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by mx1.freebsd.org (Postfix) with SMTP id DD06B8FC08 for ; Fri, 10 Aug 2012 17:53:57 +0000 (UTC) Received: (qmail invoked by alias); 10 Aug 2012 17:53:50 -0000 Received: from p578be941.dip0.t-ipconnect.de (EHLO [192.168.0.100]) [87.139.233.65] by mail.gmx.net (mp033) with SMTP; 10 Aug 2012 19:53:50 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX18vw2BT5bwvKxeCjrmAA1nFEuNeGSrO3tYHUn0BZJ ju9Bi6l9V28zIE Message-ID: <50254AAD.40003@gmx.de> Date: Fri, 10 Aug 2012 19:53:49 +0200 From: olli hauer User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: <0B65D7562F9DA04FAC3F15C508BF67136B90E09E1F@ESESSCMS0355.eemea.ericsson.se> <001701cd7648$c2520350$46f609f0$@com> <5024f984.45ca320a.1838.4155SMTPIN_ADDED@mx.google.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 10 Aug 2012 17:53:58 -0000 On 2012-08-10 16:40, Simon L. B. Nielsen wrote: > On Fri, Aug 10, 2012 at 1:06 PM, Roberto wrote: >> >> So as far I understand, if the kernel is not updated by the update process, it >> is not possible to get via "uname" the currently patch level. > > Correct. > > This has been discussed a number of time, but there are no nice and > simple solution. There is a simple solution if we just update the > kernel always, but that's a hack IMO. > > While the problem seems rather simple, there are many corner cases > making it hard to solve. It should be solved so people can get this > information, personally I just haven't had the time to work on it. > Maybe this information can be hold in an additional file, see http://cpe.mitre.org/ There is no guaranty root modifies the cpe files but thats the same for all systems which have cpe already implemented. -- Regards, olli