From owner-freebsd-security@FreeBSD.ORG Sun Aug 19 12:33:15 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 9F2EF106566C; Sun, 19 Aug 2012 12:33:15 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 33DB48FC08; Sun, 19 Aug 2012 12:33:15 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 4E6DF1DD6A5; Sun, 19 Aug 2012 14:33:14 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 2B56F2847B; Sun, 19 Aug 2012 14:33:14 +0200 (CEST) Date: Sun, 19 Aug 2012 14:33:14 +0200 From: Jilles Tjoelker To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20120819123313.GA72985@stack.nl> References: <0B65D7562F9DA04FAC3F15C508BF67136B90E09E1F@ESESSCMS0355.eemea.ericsson.se> <001701cd7648$c2520350$46f609f0$@com> <5024f984.45ca320a.1838.4155SMTPIN_ADDED@mx.google.com> <86pq6xs0zb.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86pq6xs0zb.fsf@ds4.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, Roberto , "Simon L. B. Nielsen" 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: Sun, 19 Aug 2012 12:33:15 -0000 On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Smørgrav wrote: > "Simon L. B. Nielsen" writes: > > This has been discussed a number of time, but there are no nice and > > simple solution. > There is a simple solution that, while not bulletproof, would work well > enough in most cases: have 'make installworld' create /etc/issue, which > would look like this: > FreeBSD 9.0-RELEASE-p4 amd64/amd64 I think the idea of having 'make installworld' create something is good, but we should not hard-code policy by writing the information into a file that may be shown to unauthenticated users (such as by getty). A new file with a name=value format somewhat like /etc/lsb-release on Linux seems more appropriate. If the admin wants /etc/issue, /etc/rc.d/motd can create it. The new file is not a configuration file and tools like mergemaster and freebsd-update must not bother the admin about it. If all files under /etc are considered "configuration files", then perhaps a different location is better. -- Jilles Tjoelker From owner-freebsd-security@FreeBSD.ORG Sun Aug 19 21:12:53 2012 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by hub.freebsd.org (Postfix) with ESMTP id 131FF106564A; Sun, 19 Aug 2012 21:12:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from opti.dougb.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id B59E714DA05; Sun, 19 Aug 2012 21:12:52 +0000 (UTC) Message-ID: <503156D4.3020800@FreeBSD.org> Date: Sun, 19 Aug 2012 14:12:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120728 Thunderbird/14.0 MIME-Version: 1.0 To: Jilles Tjoelker References: <0B65D7562F9DA04FAC3F15C508BF67136B90E09E1F@ESESSCMS0355.eemea.ericsson.se> <001701cd7648$c2520350$46f609f0$@com> <5024f984.45ca320a.1838.4155SMTPIN_ADDED@mx.google.com> <86pq6xs0zb.fsf@ds4.des.no> <20120819123313.GA72985@stack.nl> In-Reply-To: <20120819123313.GA72985@stack.nl> X-Enigmail-Version: 1.4.3 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Roberto , "Simon L. B. Nielsen" , 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: Sun, 19 Aug 2012 21:12:53 -0000 On 08/19/2012 05:33, Jilles Tjoelker wrote: > I think the idea of having 'make installworld' create something is good, > but we should not hard-code policy by writing the information into a > file that may be shown to unauthenticated users (such as by getty). > > A new file with a name=value format somewhat like /etc/lsb-release on > Linux seems more appropriate. If the admin wants /etc/issue, > /etc/rc.d/motd can create it. > > The new file is not a configuration file and tools like mergemaster and > freebsd-update must not bother the admin about it. If all files under > /etc are considered "configuration files", then perhaps a different > location is better. The way that you avoid mergemaster dealing with a file is to avoid installing it as part of the process that mergemaster uses to create the temproot directory (you can see this easily enough in the script). If the file doesn't end up in the temproot, mergemaster will have no knowledge of it. hth, Doug -- I am only one, but I am one. I cannot do everything, but I can do something. And I will not let what I cannot do interfere with what I can do. -- Edward Everett Hale, (1822 - 1909) 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 From owner-freebsd-security@FreeBSD.ORG Mon Aug 20 21:06:52 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 501A21065675 for ; Mon, 20 Aug 2012 21:06:52 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id BD66A8FC15 for ; Mon, 20 Aug 2012 21:06:51 +0000 (UTC) Received: from aspire.rulingia.com (12.58.233.220.static.exetel.com.au [220.233.58.12]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id q7KL6eHB079326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Aug 2012 07:06:42 +1000 (EST) (envelope-from peter@rulingia.com) Received: from aspire.rulingia.com (localhost [127.0.0.1]) by aspire.rulingia.com (8.14.5/8.14.5) with ESMTP id q7KL4mBG042872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Aug 2012 07:05:18 +1000 (EST) (envelope-from peter@aspire.rulingia.com) Received: (from peter@localhost) by aspire.rulingia.com (8.14.5/8.14.5/Submit) id q7KL4l1r042871; Tue, 21 Aug 2012 07:04:47 +1000 (EST) (envelope-from peter) Date: Tue, 21 Aug 2012 07:04:47 +1000 From: Peter Jeremy To: Paul Schenkeveld Message-ID: <20120820210447.GB27130@aspire.rulingia.com> References: <31946.192.168.0.107.1344505442.squirrel@mail.redix.it:443> <20120819144637.GA17778@psconsult.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kXdP64Ggrk/fb43R" Content-Disposition: inline In-Reply-To: <20120819144637.GA17778@psconsult.nl> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 20 Aug 2012 21:06:52 -0000 --kXdP64Ggrk/fb43R Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-Aug-19 16:46:37 +0200, Paul Schenkeveld wrot= e: > - 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. I'm not sure what detail you intend here. One line per installworld or similar sounds OK. One line per file seems excessive - especially if you intend to retain history ("df -ki" suggests that a base install is around 30,000 files). > - 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 How do you envisage this tool determining that /usr/sbin/foo is at 8.3-RELEASE-p2 and this is incorrect when userland is at (eg) 8.3-RELEASE-p4? Note that updating your system from 8.3-RELEASE-p2 to 8.3-RELEASE-p4 may not change /usr/sbin/foo and therefore it will remain untouched. >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. SSH includes provision for displaying information prior to login - see the "Banner" option in sshd_config. Note that this is most definitely the wrong place to include system version details. --=20 Peter Jeremy --kXdP64Ggrk/fb43R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlAypm8ACgkQ/opHv/APuIdJ5ACeMNFbmDyks/bni7oOYELRc/A/ zRYAoLQEjQHx8s5718YGvF0F82XzTuTu =jh8H -----END PGP SIGNATURE----- --kXdP64Ggrk/fb43R-- From owner-freebsd-security@FreeBSD.ORG Mon Aug 20 21:25:16 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 281F0106564A; Mon, 20 Aug 2012 21:25:16 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (emx.nitro.dk [IPv6:2a01:4f8:120:7384::102]) by mx1.freebsd.org (Postfix) with ESMTP id A74AE8FC0C; Mon, 20 Aug 2012 21:25:15 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id D0F0C2B573A; Mon, 20 Aug 2012 21:25:14 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id Iuz68t91ZSFk; Mon, 20 Aug 2012 21:25:12 +0000 (UTC) Received: from zaphod.local (unknown [89.100.2.68]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 75F4A2B5736; Mon, 20 Aug 2012 21:25:12 +0000 (UTC) Message-ID: <5032AB28.9070306@FreeBSD.org> Date: Mon, 20 Aug 2012 22:24:56 +0100 From: "Simon L. B. Nielsen" Organization: FreeBSD Security Team User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-security@FreeBSD.org, freebsd-current@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0A5E7BB9CE9D73AFB4E2313" Cc: Subject: [HEADSUP] geli(4) weak master key generation on -CURRENT 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 21:25:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0A5E7BB9CE9D73AFB4E2313 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely ignore this mail. If you are, please read on! -CURRENT users of geli(4) should be advised that, a geli(4) device may have weak master key, if the provider is created on -CURRENT system built against source code between r238116 (Jul 4 17:54:17 2012 UTC) and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). One can verify if its provider was created with weak keys by running: # geli dump | grep version If the version is 7 and the system did not include this fix (r239184) when provider was initialized, then the data has to be backed up, underlying provider overwritten with random data, system upgraded and provider recreated. Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for fixing it, and Xin Li for drafting this text. PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't supported by the FreeBSD Security Team, we are not releasing an advisory, just this heads up. --=20 Simon L. B. Nielsen FreeBSD Security Officer --------------enigC0A5E7BB9CE9D73AFB4E2313 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAyqzcACgkQFdaIBMps37LryQCfSCa1m271tv/9b1Wsr88++C2M cNYAmweTW7GrVIy4EYtsuza/s5Jd5wKq =N/Dw -----END PGP SIGNATURE----- --------------enigC0A5E7BB9CE9D73AFB4E2313-- From owner-freebsd-security@FreeBSD.ORG Mon Aug 20 22:23:21 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 4B2611065670; Mon, 20 Aug 2012 22:23:21 +0000 (UTC) (envelope-from simon@FreeBSD.org) Received: from emx.nitro.dk (leto.nitro.dk [178.63.52.6]) by mx1.freebsd.org (Postfix) with ESMTP id C2DA38FC08; Mon, 20 Aug 2012 22:23:20 +0000 (UTC) Received: from mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) by emx.nitro.dk (Postfix) with ESMTP id 64E362B5B12; Mon, 20 Aug 2012 22:23:14 +0000 (UTC) Received: from emx.nitro.dk ([127.0.1.2]) by mailscan.leto.nitro.dk (mailscan.leto.nitro.dk [127.0.1.4]) (amavisd-new, port 10024) with LMTP id rX4dJfmPn9he; Mon, 20 Aug 2012 22:23:11 +0000 (UTC) Received: from [192.168.4.24] (unknown [89.100.2.68]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by emx.nitro.dk (Postfix) with ESMTPSA id 2342E2B5B0E; Mon, 20 Aug 2012 22:23:11 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: "Simon L. B. Nielsen" In-Reply-To: <20120819123313.GA72985@stack.nl> Date: Mon, 20 Aug 2012 23:23:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D4615C7-F7CC-4BA2-A644-1D7D8DC8C38F@FreeBSD.org> References: <0B65D7562F9DA04FAC3F15C508BF67136B90E09E1F@ESESSCMS0355.eemea.ericsson.se> <001701cd7648$c2520350$46f609f0$@com> <5024f984.45ca320a.1838.4155SMTPIN_ADDED@mx.google.com> <86pq6xs0zb.fsf@ds4.des.no> <20120819123313.GA72985@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1485) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Roberto , "Simon L. B. Nielsen" , 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: Mon, 20 Aug 2012 22:23:21 -0000 On 19 Aug 2012, at 13:33, Jilles Tjoelker wrote: > On Sat, Aug 11, 2012 at 09:05:44PM +0200, Dag-Erling Sm=F8rgrav wrote: >> "Simon L. B. Nielsen" writes: >>> This has been discussed a number of time, but there are no nice and >>> simple solution. >=20 >> There is a simple solution that, while not bulletproof, would work = well >> enough in most cases: have 'make installworld' create /etc/issue, = which >> would look like this: >=20 >> FreeBSD 9.0-RELEASE-p4 amd64/amd64 >=20 > I think the idea of having 'make installworld' create something is = good, > but we should not hard-code policy by writing the information into a > file that may be shown to unauthenticated users (such as by getty). >=20 > A new file with a name=3Dvalue format somewhat like /etc/lsb-release = on > Linux seems more appropriate. If the admin wants /etc/issue, > /etc/rc.d/motd can create it. >=20 > The new file is not a configuration file and tools like mergemaster = and > freebsd-update must not bother the admin about it. If all files under > /etc are considered "configuration files", then perhaps a different > location is better. /etc is IMO generally expected to be managed by mergemaster etc. so I = think that's a bad location for an authoritative file. Having thought about this for a while, my preference is to have the file = with the information somewhere under /usr and be installed with a normal = installworld. That has the highest likelihood to actually matching the = rest of the userland IMO, for cases like shares /usr etc (though that's = probably less common now). If it's a text file it should probably be = under /usr/share somewhere. If it's a binary /usr/bin or possibly = /usr/libexec if more magic is made to hide it. The part I'm not yet really sure about is how to display this = information. For the freebsd-update case of userland update only, it's = possible we can do something sane and preserve our existing simple uname = based output, but I'm not sure. I haven't gone through all the different = cases to be sure. For the installworld case I'm even less sure we can = simple and sanely do the right thing considering how to handle cases = with kernel and userland seriously out of sync. A simple approach would be to just append -uX to the uname string, but = I'm not really sure if I like that... To ilustrate, if for a 9.0 system, = where kernel is patch 3 userland is patch 5, we would show FreeBSD = 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and = therefor are less likely to get it wrong. More fancy things with creating log files etc. does really solve the = issue at hand with getting the running patch level in a simple way IMO. PS. /etc/issue sounds like a file which certainly shouldn't contain = authoritative info, but if it exists should rather be generated like = /etc/motd. --=20 Simon L. B. Nielsen From owner-freebsd-security@FreeBSD.ORG Tue Aug 21 13:37:17 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 6D7A810656D2 for ; Tue, 21 Aug 2012 13:37:17 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2FB048FC17 for ; Tue, 21 Aug 2012 13:37:17 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 3FF78672E for ; Tue, 21 Aug 2012 15:37:16 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id EB089894B; Tue, 21 Aug 2012 15:37:15 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: freebsd-security@freebsd.org Date: Tue, 21 Aug 2012 15:37:14 +0200 Message-ID: <86393gpdrp.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Hardware TOTP tokens 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: Tue, 21 Aug 2012 13:37:17 -0000 I'm looking for *rekeyable* TOTP (RFC 6238) tokens - preferably, but not necessarily OATH-certified. Does anyone know where I can find something like that? Alternatively, does anyone know of a reasonably-priced device that can be used to implement this? The requirements are very modest - a cheap microcontroller with a few kB of EEPROM and few kB of RAM, a reasonably precise real-time clock, and a six-digit seven-segment display, all in a package the size of a pack of gum. Note that we're not talking about large volumes - I need a few hundred, at most. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Tue Aug 21 14:32:06 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 58458106566C for ; Tue, 21 Aug 2012 14:32:06 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 162218FC1E for ; Tue, 21 Aug 2012 14:32:06 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id q7LEW5Zo002741; Tue, 21 Aug 2012 10:32:05 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <50339BDA.7080002@sentex.net> Date: Tue, 21 Aug 2012 10:31:54 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Subject: Re: Default password encryption method. 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: Tue, 21 Aug 2012 14:32:06 -0000 On 6/19/2012 10:10 AM, ian ivy wrote: > By default FreeBSD uses MD5 to encrypt passwords. MD5 is believed to be > more secure than e.g. DES but less than e.g. SHA512. Currently several > major Linux distributions, uses a SHA512 mechanism. Suse Linux also offers > a blowfish. A late followup to this thread, but there was a decent fleshed out article on this issue http://arstechnica.com/security/2012/08/passwords-under-assault/ There are a few caveats/clarifications in the comments, but pretty good overall for a non hardcore crypto audience. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 21 15:56:22 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 A9FB5106566C for ; Tue, 21 Aug 2012 15:56:22 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) by mx1.freebsd.org (Postfix) with ESMTP id 896548FC19 for ; Tue, 21 Aug 2012 15:56:22 +0000 (UTC) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) by mx5.roble.com (Postfix) with ESMTP id 5473967840 for ; Tue, 21 Aug 2012 08:49:32 -0700 (PDT) Date: Tue, 21 Aug 2012 08:49:32 -0700 (PDT) From: Roger Marquis To: freebsd-security@freebsd.org In-Reply-To: <20120821120031.9B0771065674@hub.freebsd.org> References: <20120821120031.9B0771065674@hub.freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Message-Id: <20120821155622.A9FB5106566C@hub.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: Tue, 21 Aug 2012 15:56:22 -0000 Jilles Tjoelker wrote: > I think the idea of having 'make installworld' create something is good, > but we should not hard-code policy by writing the information into a > file that may be shown to unauthenticated users (such as by getty). > > A new file with a name=value format somewhat like /etc/lsb-release on > Linux seems more appropriate. If the admin wants /etc/issue, > /etc/rc.d/motd can create it. Automatically updating /etc/issue (or /etc/issue.net, but not issue.* should that be adopted from other OS) has security implications due to potentially unintended information disclosure. WRT writing a new file, something like /etc/bsd-release would be a good choice following the principle of least surprise. Mergemaster can and should ignore it (and motd, issue, ...). Strict adherence to the KIS principle, however, would only write this information to the first line of the motd, after the kernel info. Simon Nielsen wrote: > A simple approach would be to just append -uX to the uname string, but I'm > not really sure if I like that... To ilustrate, if for a 9.0 system, where > kernel is patch 3 userland is patch 5, we would show FreeBSD > 9.0-RELEASE-p3-u5. The nice thing is that we don't try to be clever and > therefor are less likely to get it wrong. There's not a good way to report on every userland (lib/binary) file but a simple find and/or checksum (a la integrit) could indicate whether anything had been updated since the last installworld. That could be noted by appending a simple "-modified" to whatever uname prints for the userland version. Attempting to do more than that, IMO, would have a negative ROI. IMO, Roger Marquis From owner-freebsd-security@FreeBSD.ORG Tue Aug 21 16:03:50 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 38A45106564A for ; Tue, 21 Aug 2012 16:03:50 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 1A48E8FC08 for ; Tue, 21 Aug 2012 16:03:49 +0000 (UTC) Received: from Xins-MacBook-Pro.local (unknown [IPv6:2001:470:83bf:0:a0dd:a42a:75b4:d811]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 14B561DDBE; Tue, 21 Aug 2012 09:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1345565025; bh=sEkhfr4i4IJuzgjzTMKvhIh0g4W5IbfAcR5uJO9KOkM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=gKGw3FNNk/U/f4RGIvcwtPjQEnpxVw0nFVelduwunXV289a4SBFiYDI0m97R7t20K 4BIbRkBcydZ6ZTd271rs2IGageBxXLCXodtfrYU1MZLY/uKdoeqg22NakQActcEgQD dE2eK6n1xgVfrZhvlIBRGpEgWAyo9ggKMDRhTQgM= Message-ID: <5033B15F.3020905@delphij.net> Date: Tue, 21 Aug 2012 09:03:43 -0700 From: Xin Li Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbcO4cmdyYXY=?= References: <86393gpdrp.fsf@ds4.des.no> In-Reply-To: <86393gpdrp.fsf@ds4.des.no> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-security@freebsd.org Subject: Re: Hardware TOTP tokens X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:03:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 8/21/12 6:37 AM, Dag-Erling Smørgrav wrote: > I'm looking for *rekeyable* TOTP (RFC 6238) tokens - preferably, > but not necessarily OATH-certified. Does anyone know where I can > find something like that? > > Alternatively, does anyone know of a reasonably-priced device that > can be used to implement this? The requirements are very modest - > a cheap microcontroller with a few kB of EEPROM and few kB of RAM, > a reasonably precise real-time clock, and a six-digit seven-segment > display, all in a package the size of a pack of gum. > > Note that we're not talking about large volumes - I need a few > hundred, at most. Is it intentional to avoid Google Authenticator? (I would consider it because it's relatively easier to synchronize time and easy to notice when they are missing but yes, the end user needs an Android or iOS based smartphone and it's a hassle when they migrate). Cheers, -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBCAAGBQJQM7FfAAoJEG80Jeu8UPuzguoH+gJBM0jr1CV+2uZ89aEVoR6A 6fjilvIYO/v8X5a6P5Lv6TJ8jZKgFM0lWJW18xP+CDQ9haPNE7CjR3eMaqcrbI3j 3MbvDp3o+TsjhV1Pht5r+vSEEmmFJRq1Bp0YOvzTn20VrxT3+aNAkzc0UyXERV3g 1rtHnt7RAsSbBpH9D8IOP5bilxAdW82Cws68fUnqTU6DjFkVX4JmzBBMiqW7h7Ps YlO1Os1OytJOuL+bZDnAtnwkUfqHAA3VPp3bu53gDve+YsDXffKpnYZx4FIpsvAn EJP1oN2bVBFug4g94YtLBUTJGSTOBE0et5gOxkeSutDadgQiwc28ZKx1/dBzTy4= =BmVW -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Tue Aug 21 16:19:07 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 959D31065676; Tue, 21 Aug 2012 16:19:07 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) by mx1.freebsd.org (Postfix) with ESMTP id 77F238FC15; Tue, 21 Aug 2012 16:19:07 +0000 (UTC) Received: from Xins-MacBook-Pro.local (unknown [IPv6:2001:470:83bf:0:a0dd:a42a:75b4:d811]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by anubis.delphij.net (Postfix) with ESMTPSA id 005131DECE; Tue, 21 Aug 2012 09:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=delphij.net; s=anubis; t=1345565947; bh=52/M8KDcQzF3/ydAkawUU1qan8FxTx3ZDpf6XtkNa9M=; h=Date:From:Reply-To:To:CC:Subject; b=ZUa0CRGuL2MyHmXFfQviGDO6MJrYgWvj/9z5i9NI551cvwm3vyMwSZgacI0SnMs5e rkxj4OIU8urSSyVmDa2e/EUaD3K6b+Ie9RUfXJUe1zPMt19vDozs6TQCbhCoZMkR27 a5BvyV6GvfcjJPAjwISI17g2+xUiqtt5TFrG+sOo= Message-ID: <5033B4ED.20401@delphij.net> Date: Tue, 21 Aug 2012 09:18:53 -0700 From: Xin Li Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Pawel Jakub Dawidek Subject: Remotely attaching GELI provider on boot -- is this a useful feature? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 16:19:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I've been playing around GELI a little bit and come with an idea, have a prototype and wonders if this would be useful. The scenario is that a system administrator wants a system be started with only network access. In the current startup order 'geli' is started way earlier than SSH and network configuration, so in my prototype I have added a new script that runs before 'geli', starts the network and SSH and keep looking at the geli device, or someone pressed Enter on console (so 'geli' will takeover and ask for passphrase). The administrator is expected to enable root login with public key authentication and / (for base system) and /root is encrypted (for public key). Of course, this is only a prototype and there are a lot of rough edges like hardcoded geli device name, etc., but will this be useful for general consumption? - ---- #!/bin/sh # # PROVIDE: geli0 # BEFORE: disks # REQUIRE: initrandom # KEYWORD: nojail . /etc/rc.subr name="geli0" start_cmd="geli0_start" stop_cmd=":" required_modules="geom_eli:g_eli" geli0_start() { mount -uw / /etc/rc.d/devd start /etc/rc.d/hostid start /etc/rc.d/hostname start /etc/rc.d/netif start /etc/rc.d/routing start /etc/rc.d/sshd start echo -n "Waiting ada0s1d to be available, press enter to continue..." while true; do if [ -e /dev/ada0s1d.eli ]; then break fi read -t 5 dummy && break done /etc/rc.d/sshd stop /etc/rc.d/routing stop /etc/rc.d/netif stop /etc/rc.d/devd stop } load_rc_config $name run_rc_command "$1" - ---- -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQEcBAEBCAAGBQJQM7TtAAoJEG80Jeu8UPuzVTwH/Ami0s3CdAtPZzifu6SWhIQU FjIum2W6+W184jIyKJWgR97TVpWeyVPQBu1RMxnYgdgNroTlZq4QnsaD4GenJswi CzzOT01EY05nqkDSmMNTvRUXQIxIeRJc0c2yzGay6YviCRfSw2FxAFj/4rKZvMSx XRdIy6swLJAeWE9jbL3w5pZnhzK6rHo12GFIIGkHpuSnUPL8PJvOKFUWbiF4O0un li8rnNDR8bq1gy5kzaSwN138CqK6O3rN0MN3li9WC9ukFNZ6MxZ1CTNncC0pK8zD DoiYw9fAo7YTnYxBCXIiTsBsEsIjdHOAegGbwvIZaVD+2XdIKoo7v9wtjggPiQY= =aKe4 -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Wed Aug 22 05:23:26 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 AB2821065670 for ; Wed, 22 Aug 2012 05:23:26 +0000 (UTC) (envelope-from jcw@speakeasy.net) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id 805A58FC19 for ; Wed, 22 Aug 2012 05:23:26 +0000 (UTC) Received: from mail3.sea5.speakeasy.net (mail3.sea5.speakeasy.net [69.17.117.42]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id DEBAEA715AE for ; Wed, 22 Aug 2012 01:23:25 -0400 (EDT) Received: (qmail 18378 invoked from network); 22 Aug 2012 05:23:25 -0000 Received: by simscan 1.4.0 ppid: 12353, pid: 4213, t: 0.0405s scanners: clamav: 0.88.2/m:52/d:10739 Received: from unknown (HELO w16.stradamotorsports.com) (jcw@[64.81.163.126]) (envelope-sender ) by mail3.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 22 Aug 2012 05:23:25 -0000 Message-ID: <50346CCD.3020505@speakeasy.net> Date: Tue, 21 Aug 2012 22:23:25 -0700 From: "Jason C. Wells" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120630 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-security@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Heimdal Update MFC Date? 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: Wed, 22 Aug 2012 05:23:26 -0000 Any idea when the updated heimdal will get MFCed? 9.1-RELEASE? I've been keeping and eye on this for a while and am eager to see this update. Thanks, Jason From owner-freebsd-security@FreeBSD.ORG Wed Aug 22 08:52:30 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 992B0106566B for ; Wed, 22 Aug 2012 08:52:30 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5B66B8FC0C for ; Wed, 22 Aug 2012 08:52:30 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D3E276B08; Wed, 22 Aug 2012 10:52:22 +0200 (CEST) Received: by ds4.des.no (Postfix, from userid 1001) id 9746C8A87; Wed, 22 Aug 2012 10:52:22 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <86393gpdrp.fsf@ds4.des.no> <5033B15F.3020905@delphij.net> Date: Wed, 22 Aug 2012 10:52:22 +0200 In-Reply-To: <5033B15F.3020905@delphij.net> (Xin Li's message of "Tue, 21 Aug 2012 09:03:43 -0700") Message-ID: <86vcgbnwah.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Hardware TOTP tokens 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: Wed, 22 Aug 2012 08:52:30 -0000 Xin Li writes: > Dag-Erling Sm=C3=B8rgrav writes: > > I'm looking for *rekeyable* TOTP (RFC 6238) tokens - preferably, > > but not necessarily OATH-certified. Does anyone know where I can > > find something like that? > Is it intentional to avoid Google Authenticator? (I would consider it > because it's relatively easier to synchronize time and easy to notice > when they are missing but yes, the end user needs an Android or iOS > based smartphone and it's a hassle when they migrate). Google Authenticator *is* RFC 6238 TOTP. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Aug 22 10:44:28 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 CBD78106564A for ; Wed, 22 Aug 2012 10:44:28 +0000 (UTC) (envelope-from ady@ady.ro) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 836BE8FC0C for ; Wed, 22 Aug 2012 10:44:28 +0000 (UTC) Received: by yenl7 with SMTP id l7so622934yen.13 for ; Wed, 22 Aug 2012 03:44:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :x-gm-message-state; bh=+RIlSl8YJoYdSdb5ZvMwvBgt2dRXht/3YWYcm3C61hc=; b=ZB2UCZG0ChVVy6ZyfTphVDm/0hJb8YFjR57Etf5JmHMU9Gzlu/HjD7eZcsS/NLD7cg vRksQnWhmNpWLKwIrU6HlD4tr18fgP4km6wJmtx7f7PVDqpMxalzVz0n1XRHwnoexfe8 7jbHaExuymM1Zs/JM2V8wwRm7wTIxc83XpYPlSBEvaNajsIXo40DUvzlLwrpPrt4Mzh/ F+Ec8d4w22Sm8UZx3Y0BYWKJkR2z3/Nw1+TX3yfFhBkO6AghaE04oVrPFw760HDSmcyy EcvIEaRdZXwlkfxlNSYhIUO/EOGhGAzLdG5yZpb2lBjoejRe9enK3FZgYHYazuTSx+04 jTEw== Received: by 10.50.173.2 with SMTP id bg2mr1666286igc.1.1345632267226; Wed, 22 Aug 2012 03:44:27 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.64.44.36 with HTTP; Wed, 22 Aug 2012 03:44:07 -0700 (PDT) In-Reply-To: <20120821155622.A9FB5106566C@hub.freebsd.org> References: <20120821120031.9B0771065674@hub.freebsd.org> <20120821155622.A9FB5106566C@hub.freebsd.org> From: Adrian Penisoara Date: Wed, 22 Aug 2012 13:44:07 +0300 X-Google-Sender-Auth: vhLLiz8fH9G4LJch4OnCF9IdZQc Message-ID: To: Roger Marquis Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlnNfPdFVvoYRVrDXSLpmPm7/PXQZmqYa4hrTydbsPkit4bARhESeH1nhooImkt1jJtyWDD X-Mailman-Approved-At: Wed, 22 Aug 2012 11:12:56 +0000 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: Wed, 22 Aug 2012 10:44:28 -0000 Hello, On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote: > Jilles Tjoelker wrote: [...] > > WRT writing a new file, something like /etc/bsd-release would be a good > choice following the principle of least surprise. Mergemaster can and > should ignore it (and motd, issue, ...). > I support the idea of using an /etc/*-release file to tag (and this makes me think about /var/db/freebsd-update/tag) the current release version details of the system (not only the kernel, but the whole installed system). This seems to be a popular choice among Linux distributions and thus ISV's should feel comfortable with the approach. Mergemaster and/or other updating mechanisms should update the file to reflect the reality after upgrades/updates. Now the format of the file would be also debatable: other vendors releasing derivative works from the main FreeBSD source tree (like FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should we retain only the vendor's release tag or should we have a multiple entries (for the original FreeBSD version and the vendor) ? Should we even think about multiple ${vendor}-release files or just bsd-release ? Thanks for your time, Adrian Penisoara EntepriseBSD From owner-freebsd-security@FreeBSD.ORG Wed Aug 22 11:40:45 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 4753B106564A for ; Wed, 22 Aug 2012 11:40:45 +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 A8AE08FC15 for ; Wed, 22 Aug 2012 11:40:44 +0000 (UTC) Received: (qmail invoked by alias); 22 Aug 2012 11:40:37 -0000 Received: from hu5.abaxx.de (EHLO [10.6.25.100]) [213.61.170.110] by mail.gmx.net (mp029) with SMTP; 22 Aug 2012 13:40:37 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX18HsMZoWIIH6CoOvqkBASyRx8E5oL0FfwWUttiORB 7LMqF2/EJ+iADB Message-ID: <5034C535.5060603@gmx.de> Date: Wed, 22 Aug 2012 13:40:37 +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: <20120821120031.9B0771065674@hub.freebsd.org> <20120821155622.A9FB5106566C@hub.freebsd.org> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Adrian Penisoara , Roger Marquis 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: Wed, 22 Aug 2012 11:40:45 -0000 On 2012-08-22 12:44, Adrian Penisoara wrote: > Hello, > > On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote: >> Jilles Tjoelker wrote: > [...] >> >> WRT writing a new file, something like /etc/bsd-release would be a good >> choice following the principle of least surprise. Mergemaster can and >> should ignore it (and motd, issue, ...). >> > > I support the idea of using an /etc/*-release file to tag (and this > makes me think about /var/db/freebsd-update/tag) the current release > version details of the system (not only the kernel, but the whole > installed system). This seems to be a popular choice among Linux > distributions and thus ISV's should feel comfortable with the > approach. > > Mergemaster and/or other updating mechanisms should update the file > to reflect the reality after upgrades/updates. > > Now the format of the file would be also debatable: other vendors > releasing derivative works from the main FreeBSD source tree (like > FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should > we retain only the vendor's release tag or should we have a multiple > entries (for the original FreeBSD version and the vendor) ? Should we > even think about multiple ${vendor}-release files or just bsd-release > ? In case a new file will be used, I suggest using the cpe framework, see http://cpe.mitre.org/specification/ Using a standard framework makes it easier to write platform independent tools for example in visualization environments. sample /etc/system-release-cpe entry cpe:/o:freebsd:8.3:ga:x64 ... -- Regards, olli From owner-freebsd-security@FreeBSD.ORG Wed Aug 22 11:49:47 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 66AC0106564A for ; Wed, 22 Aug 2012 11:49:47 +0000 (UTC) (envelope-from ohauer@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id CA7C18FC0C for ; Wed, 22 Aug 2012 11:49:46 +0000 (UTC) Received: (qmail invoked by alias); 22 Aug 2012 11:49:44 -0000 Received: from hu5.abaxx.de (EHLO [10.6.25.100]) [213.61.170.110] by mail.gmx.net (mp072) with SMTP; 22 Aug 2012 13:49:44 +0200 X-Authenticated: #1956535 X-Provags-ID: V01U2FsdGVkX1+xcFwUF7mxdIzHl8s1RgLg0Cn8DdfiJbAtQb5/09 hT/AvjP7otRx3+ Message-ID: <5034C758.5060207@gmx.de> Date: Wed, 22 Aug 2012 13:49:44 +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: <20120821120031.9B0771065674@hub.freebsd.org> <20120821155622.A9FB5106566C@hub.freebsd.org> <5034C535.5060603@gmx.de> In-Reply-To: <5034C535.5060603@gmx.de> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 22 Aug 2012 11:49:47 -0000 On 2012-08-22 13:40, olli hauer wrote: > On 2012-08-22 12:44, Adrian Penisoara wrote: >> Hello, >> >> On Tue, Aug 21, 2012 at 6:49 PM, Roger Marquis wrote: >>> Jilles Tjoelker wrote: >> [...] >>> >>> WRT writing a new file, something like /etc/bsd-release would be a good >>> choice following the principle of least surprise. Mergemaster can and >>> should ignore it (and motd, issue, ...). >>> >> >> I support the idea of using an /etc/*-release file to tag (and this >> makes me think about /var/db/freebsd-update/tag) the current release >> version details of the system (not only the kernel, but the whole >> installed system). This seems to be a popular choice among Linux >> distributions and thus ISV's should feel comfortable with the >> approach. >> >> Mergemaster and/or other updating mechanisms should update the file >> to reflect the reality after upgrades/updates. >> >> Now the format of the file would be also debatable: other vendors >> releasing derivative works from the main FreeBSD source tree (like >> FreeNAS, PC-BSD, etc.) will want to leave some marks as well. Should >> we retain only the vendor's release tag or should we have a multiple >> entries (for the original FreeBSD version and the vendor) ? Should we >> even think about multiple ${vendor}-release files or just bsd-release >> ? > > In case a new file will be used, I suggest using the cpe framework, > see http://cpe.mitre.org/specification/ > > Using a standard framework makes it easier to write platform > independent tools for example in visualization environments. s/visualization/virtualization/ > > sample /etc/system-release-cpe entry > cpe:/o:freebsd:8.3:ga:x64 ... From owner-freebsd-security@FreeBSD.ORG Fri Aug 24 08:23:18 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 A1FA3106564A for ; Fri, 24 Aug 2012 08:23:18 +0000 (UTC) (envelope-from simon@qxnitro.org) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5540E8FC14 for ; Fri, 24 Aug 2012 08:23:17 +0000 (UTC) Received: by ialo14 with SMTP id o14so3679556ial.13 for ; Fri, 24 Aug 2012 01:23:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hSMFO0VGP35aVacVzgg9kgxO8YT2MigCIsL7OZ1A6D8=; b=nCrl1dCykCrT8vwv2Wrcx+EHmdbQ0L8SbdJEEwssq1IM/DRrcutKILmrAmZ+9l/dYn o49SfBFDJHcgGDoErFZKsGbOAtIzjVoaCSLhSVP2hcoFgff2uTeKeGsPxqKoVldzha3/ 0omRpxpEIGVy5L7S9/i0txX4b+Z3dRiqB+9o0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=hSMFO0VGP35aVacVzgg9kgxO8YT2MigCIsL7OZ1A6D8=; b=RQxEwGz4VgeWy8c+Wpfgfo0JiopoDr60/DiJPAkYMJI1E7p1oRkxWHJqXxJWlu+JKL aZ0e8tHFW5dL6YDSB3xXF7plMRKdPWU6hrMd4tEOlaIpbTwFUyl5hAe7yZmCgCedX9qK 2tmIzpaTi85CDGnWg4uUTSC6AWXpJgY2M+JVRIblRQOxXkqxNGVoJ4dHHULmFi6MMmAV uzQXQZpJbe3cHrYa6HVCbxLBkMcUBLoIDwnIj623K6rWexQ0q1eMoX9A9sZqm746Qgo6 LDJWhFFnL1SAWVwN+qqy892FgvymG4ymlm9S5pKrEYAwfoSVBIlyVDocc3tz3wwr1uMG bJSw== MIME-Version: 1.0 Received: by 10.50.87.227 with SMTP id bb3mr1194126igb.57.1345796597329; Fri, 24 Aug 2012 01:23:17 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.64.102.104 with HTTP; Fri, 24 Aug 2012 01:23:17 -0700 (PDT) X-Originating-IP: [2620:0:1040:201:9db5:5be0:5543:2221] In-Reply-To: <86393gpdrp.fsf@ds4.des.no> References: <86393gpdrp.fsf@ds4.des.no> Date: Fri, 24 Aug 2012 09:23:17 +0100 X-Google-Sender-Auth: PTKlpDIy7WOR3ljOcXPTSRCoc2U Message-ID: From: "Simon L. B. Nielsen" To: =?UTF-8?Q?Dag=2DErling_Sm=C3=B8rgrav?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm5jtM/W9gjngCI6ZOwboryNH1odl+f3+NfcRL42SjNyAcDtjEE2wE/39y2Zy3iZgGHNLBR Cc: freebsd-security@freebsd.org Subject: Re: Hardware TOTP tokens 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 08:23:18 -0000 On Tue, Aug 21, 2012 at 2:37 PM, Dag-Erling Sm=C3=B8rgrav wrot= e: > I'm looking for *rekeyable* TOTP (RFC 6238) tokens - preferably, but not > necessarily OATH-certified. Does anyone know where I can find something > like that? The Aladdin eToken PASS is a very simple one, though I haven't been able to find docs on how your initialize or administer them. http://www.safenet-inc.com/products/data-protection/two-factor-authenticati= on/etoken-pass/ They are sort of programable too if you really want: https://www.youtube.com/watch?v=3DQiTNlSgk-xY :-) --=20 Simon L. B. Nielsen 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 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 From owner-freebsd-security@FreeBSD.ORG Fri Aug 24 15:51:25 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 52E0E1065670 for ; Fri, 24 Aug 2012 15:51:25 +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 08BB08FC21 for ; Fri, 24 Aug 2012 15:51:24 +0000 (UTC) Received: by obbun3 with SMTP id un3so5900053obb.13 for ; Fri, 24 Aug 2012 08:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qxnitro.org; s=google; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=72mTIhSEsmdYeImhKkR4ZtlStRj/dkI7FSimwKU4miA=; b=GphMNkMPB3rh/3S3KCDM00ohza4tEzslTpMhChUGSiJVKrnBdtADJRrRCC5YuvZRxa q+Q5MuKxsDUUurt7PdSjgo01ExNp5m/cw2nvRZUxV27LEpM8uQcoXuF7ANq6coBRdrL6 lwYq1VLkYtLsMUUoJmfAJkuBhgodwpE+jPVVU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding:x-gm-message-state; bh=72mTIhSEsmdYeImhKkR4ZtlStRj/dkI7FSimwKU4miA=; b=YEyNATIMR/8NQijl/rBxyMi+LfFSpE7b/4D7+JJWlt0bQMUm0WTONEhRYJYN5Oowf4 VvTvPAwkUnqxR3d7nKB+umoItJ2SYAgW7kTjkszX7Z8VoFnwW6ApWxcRDf/QAC14vK0+ YaAb5VcvAsMtHJcAAn/B8BLbx/VmBf1OaTaVJRzJBj70B79DST64DO6m0grroEbh5wLZ FGDAAm7Dr5tErRZvewAOMP9s4RtXabjbfn9SxPG7M8hoLsWgmYHbJsYEfHaY+PzKFkDs Okf2tvB13/ZNGeby15b6Kp5PtuLiZNyrVN0VHLBa5k4KQOWEpmz2yYQq+4pap8yHlXtM h1og== MIME-Version: 1.0 Received: by 10.60.20.99 with SMTP id m3mr4280282oee.124.1345823484386; Fri, 24 Aug 2012 08:51:24 -0700 (PDT) Sender: simon@qxnitro.org Received: by 10.76.85.135 with HTTP; Fri, 24 Aug 2012 08:51:24 -0700 (PDT) X-Originating-IP: [2620:0:1040:201:9db5:5be0:5543:2221] In-Reply-To: <20120821120537.GL1202@acme.spoerlein.net> References: <5032AB28.9070306@FreeBSD.org> <20120821120537.GL1202@acme.spoerlein.net> Date: Fri, 24 Aug 2012 16:51:24 +0100 X-Google-Sender-Auth: hLKKXpa--7TtOiRvcrLu1pM1G-U Message-ID: From: "Simon L. B. Nielsen" To: freebsd-security@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlONxwAU54lxZpl1YhYpjiXfuRqy8Yxjwrhr1q7N2GuiNp4crA7Q394x/IE9tkoFB2gd11o Cc: Subject: Re: [HEADSUP] geli(4) weak master key generation on -CURRENT 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:51:25 -0000 On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Sp=C3=B6rlein wro= te: > On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: >> Hello, >> >> If you are not using geli(4) on -CURRENT (AKA FreeBSD 10) you can safely >> ignore this mail. If you are, please read on! >> >> -CURRENT users of geli(4) should be advised that, a geli(4) device may >> have weak master key, if the provider is created on -CURRENT system >> built against source code between r238116 (Jul 4 17:54:17 2012 UTC) >> and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). >> >> One can verify if its provider was created with weak keys by running: >> >> # geli dump | grep version >> >> If the version is 7 and the system did not include this fix (r239184) >> when provider was initialized, then the data has to be backed up, >> underlying provider overwritten with random data, system upgraded and >> provider recreated. >> >> Thanks to Fabian Keil for reporting the issue, Pawel Jakub Dawidek for >> fixing it, and Xin Li for drafting this text. >> >> PS. This only affects FreeBSD 10 / -CURRENT, and as -CURRENT isn't >> supported by the FreeBSD Security Team, we are not releasing an >> advisory, just this heads up. > > I haven't read commit mails in a very long time, but is there code in > place that will issue a warning upon geli attach if version 7 is > detected? While -CURRENT is not supported, there might be a lot of disks > initialized with version 7 and they'll eventually be upgraded to > 10.0-RELEASE (the OS, not necessarily the geli volumes). No, the bad code was only in head for about a month. I'm fine with having a warning, but somebody has to code it. --=20 Simon L. B. Nielsen From owner-freebsd-security@FreeBSD.ORG Fri Aug 24 17:28:50 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 1860A106566B for ; Fri, 24 Aug 2012 17:28:50 +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 95EBD8FC12 for ; Fri, 24 Aug 2012 17:28:48 +0000 (UTC) Received: from conversation.bsdunix.ch (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 451641272D for ; Fri, 24 Aug 2012 17:28:48 +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 I6njWuIijk4O for ; Fri, 24 Aug 2012 17:28:47 +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 8B1D91272A for ; Fri, 24 Aug 2012 17:28:47 +0000 (UTC) Message-ID: <5037B9CF.2010708@bsdunix.ch> Date: Fri, 24 Aug 2012 19:28:47 +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: <20120819144637.GA17778@psconsult.nl> <50377929.3060106@bsdunix.ch> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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 17:28:50 -0000 On 8/24/12 5:49 PM, Simon L. B. Nielsen wrote: > 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? > It would be nice if this could be part of a MIB for bsnmpd(1) in base or net-snmp in ports. FreeBSD-MIB for bsnmpd(1) uses uname(3) for freeBSDVersion OBJECT-IDENTITY but according to the comments in FreeBSD-MIB.txt it can be overwritten. Not sure what net-snmp is using. Regards, Thomas From owner-freebsd-security@FreeBSD.ORG Sat Aug 25 20:43:28 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 BEE61106564A; Sat, 25 Aug 2012 20:43:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by mx1.freebsd.org (Postfix) with ESMTP id 4EF098FC12; Sat, 25 Aug 2012 20:43:27 +0000 (UTC) Received: from [78.35.178.199] (helo=fabiankeil.de) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1T5NCS-0005Zi-Mb; Sat, 25 Aug 2012 22:43:20 +0200 Date: Sat, 25 Aug 2012 22:33:31 +0200 From: Fabian Keil To: freebsd-security@freebsd.org Message-ID: <20120825223331.39d56334@fabiankeil.de> In-Reply-To: References: <5032AB28.9070306@FreeBSD.org> <20120821120537.GL1202@acme.spoerlein.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/ddw_HLgqahnHezVLZtNCKE1"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-current@freebsd.org Subject: Re: [HEADSUP] geli(4) weak master key generation on -CURRENT 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, 25 Aug 2012 20:43:28 -0000 --Sig_/ddw_HLgqahnHezVLZtNCKE1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable "Simon L. B. Nielsen" wrote: > On Tue, Aug 21, 2012 at 1:05 PM, Ulrich Sp=F6rlein wrot= e: > > On Mon, 2012-08-20 at 22:24:56 +0100, Simon L. B. Nielsen wrote: > >> -CURRENT users of geli(4) should be advised that, a geli(4) device may > >> have weak master key, if the provider is created on -CURRENT system > >> built against source code between r238116 (Jul 4 17:54:17 2012 UTC) > >> and r239184 (non-inclusive, Aug 10 18:43:29 2012 UTC). > >> > >> One can verify if its provider was created with weak keys by running: > >> > >> # geli dump | grep version > >> > >> If the version is 7 and the system did not include this fix (r239184) > >> when provider was initialized, then the data has to be backed up, > >> underlying provider overwritten with random data, system upgraded and > >> provider recreated. > > I haven't read commit mails in a very long time, but is there code in > > place that will issue a warning upon geli attach if version 7 is > > detected? While -CURRENT is not supported, there might be a lot of disks > > initialized with version 7 and they'll eventually be upgraded to > > 10.0-RELEASE (the OS, not necessarily the geli volumes). >=20 > No, the bad code was only in head for about a month. I'm fine with > having a warning, but somebody has to code it. The weak keys weren't stored on disk, but generated at attach-time. A patched kernel will generate different keys which means it shouldn't be backwards compatible to a vulnerable kernel as far as reading and writing geli version 7 is concerned. If a user doesn't follow the recommended mitigation steps and simply updates the kernel without migrating the data first, he shouldn't be able to read the encrypted data written with the previous kernel version, which I consider kinda hard to miss. I believe if there really were "a lot of disks" initialized with affected kernels, there would have been at least a couple of complaints on the mailing lists already. Fabian --Sig_/ddw_HLgqahnHezVLZtNCKE1 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlA5Np4ACgkQBYqIVf93VJ0EpgCfY9jr+hFBRWn1UAMK4x86b5Km nUoAoL8GHxYkNumdBjHTCgZ/tgYJStvz =xTKj -----END PGP SIGNATURE----- --Sig_/ddw_HLgqahnHezVLZtNCKE1--