From owner-freebsd-security@FreeBSD.ORG Tue Aug 27 15:32:19 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 952887C; Tue, 27 Aug 2013 15:32:19 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 27E2F2F58; Tue, 27 Aug 2013 15:32:18 +0000 (UTC) Received: from roberto02-aw.eurocontrol.fr (unknown [88.190.16.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 3BE4952AE; Tue, 27 Aug 2013 17:32:12 +0200 (CEST) Date: Tue, 27 Aug 2013 17:32:05 +0200 From: Ollivier Robert To: dinoex@freebsd.org Subject: security/openssl speed issues Message-ID: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-security@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 15:32:19 -0000 Hello Dirk ! As I got a new machine with the AES-NI crypto extensions, I'm getting interested with it and as you may have seen, I've already merged into stable/9 two changesets for AES-NI support in GELI & cryptodev. Now, I'm trying to measure the impact of said AES extentions, I tumbled on a very weird difference in behaviour between our base system openssl and the one in ports. /usr/bin/openssl: OpenSSL 0.9.8y 5 Feb 2013 /usr/local/bin/openssl: OpenSSL 1.0.1e 11 Feb 2013 The one is base is not supposed to have cryptodev (and aesni) support at all as it was added apparently in 1.0.1. Fine. 1. Trying to run both on a machine without the AES-NI extensions, I should have similar results in running speed tests but: 1181 [17:18] roberto@centre:/usr/ports> /usr/bin/openssl speed aes-256-cbc ... OpenSSL 0.9.8y 5 Feb 2013 (9.1-BETA1) built on: date not available options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc available timing options: USE_TOD HZ=128 [sysconf value] timing function used: getrusage The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 58919.92k 62134.88k 62611.08k 62776.47k 62910.03k and 1182 [17:19] roberto@centre:/usr/ports> /usr/local/bin/openssl speed aes-256-cbc ... OpenSSL 1.0.1e 11 Feb 2013 built on: Sun Jul 28 16:36:48 CEST 2013 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIOS -O3 -DMD32_REG_T=int -Wall -O -pipe -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 38790.95k 41415.66k 42009.00k 42257.07k 42213.38k Wow, how would you explain the 37% (in the worng direction!) difference? Is there something I could add/change in the port's configuration to fix that? 2. I have another machine with the AES-NI extensions, with a E3-1220 CPU. If I load crypto, aesni and cryptodev, it is indentified as using them: cryptosoft0: on motherboard aesni0: on motherboard Results of openssl speed with the base one are better as you would expect, CPU is faster: % /usr/bin/openssl speed aes-256-cbc ... OpenSSL 0.9.8x 10 May 2012 (9.1-RELEASE) built on: date not available options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) compiler: cc available timing options: USE_TOD HZ=128 [sysconf value] timing function used: getrusage The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 125404.07k 129849.19k 130514.37k 131242.71k 131164.72k but... % /usr/local/bin/openssl speed -engine cryptodev aes-256-cbc engine "cryptodev" set. ... OpenSSL 1.0.1c 10 May 2012 built on: Mon Apr 8 19:45:18 UTC 2013 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIOS -O3 -DMD32_REG_T=int -Wall -O2 -pipe -fno-strict-aliasing -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 71203.16k 74667.39k 75631.27k 75975.34k 76090.03k Still 42% diff and no "aesni" usage at all!? I'm guessing we have an issue there... Thanks, -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 27 16:15:02 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1359E1D6; Tue, 27 Aug 2013 16:15:02 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAC9F2213; Tue, 27 Aug 2013 16:15:01 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7RGEsFV092876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 09:14:54 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7RGEsAW092875; Tue, 27 Aug 2013 09:14:54 -0700 (PDT) (envelope-from jmg) Date: Tue, 27 Aug 2013 09:14:54 -0700 From: John-Mark Gurney To: Ollivier Robert Subject: Re: security/openssl speed issues Message-ID: <20130827161454.GL29777@funkthat.com> Mail-Followup-To: Ollivier Robert , dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 27 Aug 2013 09:14:54 -0700 (PDT) Cc: dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 16:15:02 -0000 Ollivier Robert wrote this message on Tue, Aug 27, 2013 at 17:32 +0200: > As I got a new machine with the AES-NI crypto extensions, I'm getting interested with it and as you may have seen, I've already merged into stable/9 two changesets for AES-NI support in GELI & cryptodev. > > Now, I'm trying to measure the impact of said AES extentions, I tumbled on a very weird difference in behaviour between our base system openssl and the one in ports. > > /usr/bin/openssl: > OpenSSL 0.9.8y 5 Feb 2013 > > /usr/local/bin/openssl: > OpenSSL 1.0.1e 11 Feb 2013 > > The one is base is not supposed to have cryptodev (and aesni) support at all as it was added apparently in 1.0.1. Fine. > > 1. Trying to run both on a machine without the AES-NI extensions, I should have similar results in running speed tests but: > > 1181 [17:18] roberto@centre:/usr/ports> /usr/bin/openssl speed aes-256-cbc > ... > OpenSSL 0.9.8y 5 Feb 2013 (9.1-BETA1) > built on: date not available > options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) > compiler: cc > available timing options: USE_TOD HZ=128 [sysconf value] > timing function used: getrusage > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-256 cbc 58919.92k 62134.88k 62611.08k 62776.47k 62910.03k > > and > > 1182 [17:19] roberto@centre:/usr/ports> /usr/local/bin/openssl speed aes-256-cbc > ... > OpenSSL 1.0.1e 11 Feb 2013 > built on: Sun Jul 28 16:36:48 CEST 2013 > options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) > compiler: cc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIOS -O3 -DMD32_REG_T=int -Wall -O -pipe -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-256 cbc 38790.95k 41415.66k 42009.00k 42257.07k 42213.38k > > Wow, how would you explain the 37% (in the worng direction!) difference? Is there something I could add/change in the port's configuration to fix that? > > 2. I have another machine with the AES-NI extensions, with a E3-1220 CPU. If I load crypto, aesni and cryptodev, it is indentified as using them: > > cryptosoft0: on motherboard > aesni0: on motherboard > > Results of openssl speed with the base one are better as you would expect, CPU is faster: > > % /usr/bin/openssl speed aes-256-cbc > ... > OpenSSL 0.9.8x 10 May 2012 (9.1-RELEASE) > built on: date not available > options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) > compiler: cc > available timing options: USE_TOD HZ=128 [sysconf value] > timing function used: getrusage > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-256 cbc 125404.07k 129849.19k 130514.37k 131242.71k 131164.72k > > but... > > % /usr/local/bin/openssl speed -engine cryptodev aes-256-cbc > engine "cryptodev" set. > ... > OpenSSL 1.0.1c 10 May 2012 > built on: Mon Apr 8 19:45:18 UTC 2013 > options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) > compiler: cc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DL_ENDIAN -DTERMIOS -O3 -DMD32_REG_T=int -Wall -O2 -pipe -fno-strict-aliasing -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > The 'numbers' are in 1000s of bytes per second processed. > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes > aes-256 cbc 71203.16k 74667.39k 75631.27k 75975.34k 76090.03k > > Still 42% diff and no "aesni" usage at all!? > > I'm guessing we have an issue there... I discovered a similar issue on HEAD w/ 1.0.1e where openssl speed -engine aes-256-cbc when ktraced would not issue any ioctl's during the speed test... You can see that it opens the device, but then it gets a number of failures: 11466 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd590) 11466 openssl RET ioctl -1 errno 22 Invalid argument and then you see no more ioctl's As far as I can tell, 1.0.1e doesn't properly detect AES-NI and uses these instructions when present, and cryptodev usage doesn't work, and doesn't warn when it fails... My own program that tests cryptodev out performs openssl because of this.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Tue Aug 27 17:36:03 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2865FF2E; Tue, 27 Aug 2013 17:36:03 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DF3192711; Tue, 27 Aug 2013 17:36:02 +0000 (UTC) Received: from lonrach.local (foret.keltia.net [78.232.116.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 418D252AE; Tue, 27 Aug 2013 19:36:02 +0200 (CEST) Date: Tue, 27 Aug 2013 19:35:59 +0200 From: Ollivier Robert To: dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Re: security/openssl speed issues Message-ID: <20130827173559.GB25401@lonrach.local> References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> <20130827161454.GL29777@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827161454.GL29777@funkthat.com> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 17:36:03 -0000 According to John-Mark Gurney: > As far as I can tell, 1.0.1e doesn't properly detect AES-NI and uses > these instructions when present, and cryptodev usage doesn't work, and > doesn't warn when it fails... > > My own program that tests cryptodev out performs openssl because of > this.. Yeah, that seems the second issue, the first one being that even with aesni/cryptodev out of the picture, 1.0.1 is still slower than 0.9.8... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 27 18:07:40 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EEC2366C; Tue, 27 Aug 2013 18:07:40 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B76228AB; Tue, 27 Aug 2013 18:07:40 +0000 (UTC) Received: from lonrach.local (foret.keltia.net [78.232.116.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 3849E52B1; Tue, 27 Aug 2013 20:07:40 +0200 (CEST) Date: Tue, 27 Aug 2013 20:07:37 +0200 From: Ollivier Robert To: dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Re: security/openssl speed issues Message-ID: <20130827180736.GC25401@lonrach.local> References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> <20130827161454.GL29777@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827161454.GL29777@funkthat.com> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:07:41 -0000 According to John-Mark Gurney: > I discovered a similar issue on HEAD w/ 1.0.1e where openssl speed -engine > aes-256-cbc when ktraced would not issue any ioctl's during the speed > test... You can see that it opens the device, but then it gets a number > of failures: > 11466 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd590) > 11466 openssl RET ioctl -1 errno 22 Invalid argument That is not the main problem, openssl is asking which ciphers are supported and not everything is through cryptodev. The issue is that it should issue other ioctl for the supported ciphers and my 1.0.1c does not do that. I've obtained a "ktrace.out" of a working version: ------ 23961 openssl CALL open(0x800c6874f,0x2,0) 23961 openssl NAMI "/dev/crypto" 23961 openssl RET open 3 23961 openssl CALL fcntl(0x3,F_SETFD,FD_CLOEXEC) 23961 openssl RET fcntl 0 23961 openssl CALL ioctl(0x3,CRIOGET,0x7fffffffd51c) 23961 openssl RET ioctl 0 23961 openssl CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 23961 openssl RET fcntl 0 23961 openssl CALL ioctl(0x4,CIOCASYMFEAT,0x800ec73e0) 23961 openssl RET ioctl 0 23961 openssl CALL close(0x4) 23961 openssl RET close 0 23961 openssl CALL ioctl(0x3,CRIOGET,0x7fffffffd47c) 23961 openssl RET ioctl 0 23961 openssl CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 23961 openssl RET fcntl 0 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl -1 errno 22 Invalid argument 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl -1 errno 22 Invalid argument 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl -1 errno 22 Invalid argument 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CDRIOCINITWRITER,0x7fffffffd4c8) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CDRIOCINITWRITER,0x7fffffffd4c8) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CDRIOCINITWRITER,0x7fffffffd4c8) 23961 openssl RET ioctl 0 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl -1 errno 22 Invalid argument 23961 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4a0) 23961 openssl RET ioctl -1 errno 22 Invalid argument 23961 openssl CALL close(0x4) 23961 openssl RET close 0 ------ Notice the CDRIOCINITWRITER? My run does not show these: so after these lines, there are no "sessions" available and cryptodev is in fact not used. ----- 2709 openssl CALL open(0x800c56cef,0x2,0) 2709 openssl NAMI "/dev/crypto" 2709 openssl RET open 3 2709 openssl CALL fcntl(0x3,F_SETFD,FD_CLOEXEC) 2709 openssl RET fcntl 0 2709 openssl CALL ioctl(0x3,CRIOGET,0x7fffffffd56c) 2709 openssl RET ioctl 0 2709 openssl CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 2709 openssl RET fcntl 0 2709 openssl CALL ioctl(0x4,CIOCASYMFEAT,0x800eb3fe0) 2709 openssl RET ioctl 0 2709 openssl CALL close(0x4) 2709 openssl RET close 0 2709 openssl CALL ioctl(0x3,CRIOGET,0x7fffffffd4cc) 2709 openssl RET ioctl 0 2709 openssl CALL fcntl(0x4,F_SETFD,FD_CLOEXEC) 2709 openssl RET fcntl 0 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl -1 errno 22 Invalid argument 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl -1 errno 22 Invalid argument 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl -1 errno 22 Invalid argument 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCFSESSION,0x7fffffffd518) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCFSESSION,0x7fffffffd518) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCFSESSION,0x7fffffffd518) 2709 openssl RET ioctl 0 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl -1 errno 22 Invalid argument 2709 openssl CALL ioctl(0x4,CIOCGSESSION,0x7fffffffd4f0) 2709 openssl RET ioctl -1 errno 22 Invalid argument 2709 openssl CALL close(0x4) 2709 openssl RET close 0 ----- Making progress... -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Tue Aug 27 18:46:35 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D0C09F4; Tue, 27 Aug 2013 18:46:35 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 608242B1E; Tue, 27 Aug 2013 18:46:35 +0000 (UTC) Received: from lonrach.local (foret.keltia.net [78.232.116.160]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id 4F3A752AE; Tue, 27 Aug 2013 20:46:34 +0200 (CEST) Date: Tue, 27 Aug 2013 20:46:31 +0200 From: Ollivier Robert To: dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Re: security/openssl speed issues Message-ID: <20130827184631.GD25401@lonrach.local> References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> <20130827161454.GL29777@funkthat.com> <20130827180736.GC25401@lonrach.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827180736.GC25401@lonrach.local> X-Operating-System: MacOS X / MBP 4,1 - FreeBSD 8.0 / T3500-E5520 Nehalem User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2013 18:46:35 -0000 According to Ollivier Robert: > Notice the CDRIOCINITWRITER? My run does not show these: so after these lines, there are no "sessions" available and cryptodev is in fact not used. Note to oneself, do not try to kdump a 9.1 trace file on a 9.2 system. Forget the CDRIOCINITWRITER. kdump -A output on a 9.1 system with 1.0.1e openssl from ports: http://assets.keltia.net/openssl-good.txt kdump -A output on a 9.1 system with 1.0.1e openssl from ports http://assets.keltia.net/openssl-verybad.txt -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 02:27:30 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 41049739; Wed, 28 Aug 2013 02:27:30 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EA2422321; Wed, 28 Aug 2013 02:27:29 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7S2RT4o001997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Aug 2013 19:27:29 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7S2RSZu001996; Tue, 27 Aug 2013 19:27:28 -0700 (PDT) (envelope-from jmg) Date: Tue, 27 Aug 2013 19:27:28 -0700 From: John-Mark Gurney To: Ollivier Robert Subject: Re: security/openssl speed issues Message-ID: <20130828022728.GR29777@funkthat.com> Mail-Followup-To: Ollivier Robert , dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 27 Aug 2013 19:27:29 -0700 (PDT) Cc: dinoex@freebsd.org, freebsd-security@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 02:27:30 -0000 Ollivier Robert wrote this message on Tue, Aug 27, 2013 at 17:32 +0200: > As I got a new machine with the AES-NI crypto extensions, I'm getting interested with it and as you may have seen, I've already merged into stable/9 two changesets for AES-NI support in GELI & cryptodev. > > Now, I'm trying to measure the impact of said AES extentions, I tumbled on a very weird difference in behaviour between our base system openssl and the one in ports. > > /usr/bin/openssl: > OpenSSL 0.9.8y 5 Feb 2013 > > /usr/local/bin/openssl: > OpenSSL 1.0.1e 11 Feb 2013 > > The one is base is not supposed to have cryptodev (and aesni) support at all as it was added apparently in 1.0.1. Fine. > > 1. Trying to run both on a machine without the AES-NI extensions, I should have similar results in running speed tests but: > > 1181 [17:18] roberto@centre:/usr/ports> /usr/bin/openssl speed aes-256-cbc This is not a very good way to run the tests... It turns out that if you run it this way, it will NOT go through the EVP OpenSSL system, and instead call a slow AES function directly, which will not be the one that gets used in real applications... To use the EVP system, and see what performance OpenSSH and others will get, use openssl speed -evp aes-256-cbc Now if you have cryptodev+aesni loaded and my aesni patches applied, you'll see something like this: $ openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 928863 aes-256-cbc's in 0.20s Doing aes-256-cbc for 3s on 64 size blocks: 880075 aes-256-cbc's in 0.28s Doing aes-256-cbc for 3s on 256 size blocks: 775018 aes-256-cbc's in 0.20s Doing aes-256-cbc for 3s on 1024 size blocks: 490425 aes-256-cbc's in 0.09s Doing aes-256-cbc for 3s on 8192 size blocks: 102189 aes-256-cbc's in 0.05s OpenSSL 1.0.1e-freebsd 11 Feb 2013 built on: Tue Aug 27 11:52:46 PDT 2013 options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -O The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 76092.46k 200265.96k 1015831.59k 5843725.96k 17858822.14k Man, 17GB/sec! Impressive! Except not... notice the times above.. it only took .05s to do it.. That's because by default, openssl speed only computes user time, not real time and since it's now properly using cryptodev, not much cpu time is spent in the process... The undocumented -elapsed option to the rescue: $ openssl speed -elapsed -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 962245 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 64 size blocks: 918001 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 256 size blocks: 799186 aes-256-cbc's in 3.05s Doing aes-256-cbc for 3s on 1024 size blocks: 496954 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 8192 size blocks: 102473 aes-256-cbc's in 3.00s OpenSSL 1.0.1e-freebsd 11 Feb 2013 built on: Tue Aug 27 11:52:46 PDT 2013 options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -O The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 5118.64k 19432.21k 67148.02k 168312.03k 279819.61k This gives a bit more resonable results... And if you specify -decrypt also, you'll see it's faster because w/ my aesni patches, it pipelines cbc decrypt: $ openssl speed -elapsed -decrypt -evp aes-256-cbc You have chosen to measure elapsed time instead of user CPU time. Doing aes-256-cbc for 3s on 16 size blocks: 941128 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 64 size blocks: 950875 aes-256-cbc's in 3.03s Doing aes-256-cbc for 3s on 256 size blocks: 922503 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 1024 size blocks: 750362 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 8192 size blocks: 208038 aes-256-cbc's in 3.03s OpenSSL 1.0.1e-freebsd 11 Feb 2013 built on: Tue Aug 27 11:52:46 PDT 2013 options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -O The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 4993.34k 20076.21k 78720.26k 256123.56k 562225.91k So, the good news is that cryptodev does properly work for OpenSSL... And even better news (if you unload cryptodev), OpenSSL does work with AESNI: $ openssl speed -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 56809161 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 64 size blocks: 15626726 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 256 size blocks: 4289939 aes-256-cbc's in 3.04s Doing aes-256-cbc for 3s on 1024 size blocks: 1090334 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 8192 size blocks: 136649 aes-256-cbc's in 2.99s OpenSSL 1.0.1e-freebsd 11 Feb 2013 built on: Tue Aug 27 11:52:46 PDT 2013 options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -O The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 300633.49k 332504.26k 361369.46k 370239.01k 374117.13k and decrypt is even faster: $ openssl speed -decrypt -evp aes-256-cbc Doing aes-256-cbc for 3s on 16 size blocks: 61585473 aes-256-cbc's in 3.00s Doing aes-256-cbc for 3s on 64 size blocks: 60938441 aes-256-cbc's in 3.02s Doing aes-256-cbc for 3s on 256 size blocks: 34632152 aes-256-cbc's in 3.01s Doing aes-256-cbc for 3s on 1024 size blocks: 9779213 aes-256-cbc's in 3.03s Doing aes-256-cbc for 3s on 8192 size blocks: 1320658 aes-256-cbc's in 3.05s OpenSSL 1.0.1e-freebsd 11 Feb 2013 built on: Tue Aug 27 11:52:46 PDT 2013 options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: cc -O The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 328455.86k 1289942.40k 2947600.93k 3303559.29k 3550795.60k Just for people wondering what CPU: CPU: AMD A10-5700 APU with Radeon(tm) HD Graphics (3393.89-MHz K8-class CPU) I guess now we need to figure out how to teach OpenSSL to use AES-NI natively even when /dev/crypto is available... but at least we did solve the (non-)issue of bad OpenSSL performance... I will submit a patch to OpenSSL to not make the documentation of the -elapsed option dependent on defines... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 09:18:15 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51C83FE1; Wed, 28 Aug 2013 09:18:15 +0000 (UTC) (envelope-from roberto@keltia.freenix.fr) Received: from keltia.net (aran.keltia.net [88.191.250.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1667D27D3; Wed, 28 Aug 2013 09:18:14 +0000 (UTC) Received: from roberto02-aw.eurocontrol.fr (unknown [88.190.16.243]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: roberto) by keltia.net (Postfix) with ESMTPSA id D956452AE; Wed, 28 Aug 2013 11:18:13 +0200 (CEST) Date: Wed, 28 Aug 2013 11:18:04 +0200 From: Ollivier Robert To: freebsd-security@freebsd.org, freebsd-ports@freebsd.org Subject: Re: security/openssl speed issues Message-ID: <20130828091804.GA54134@roberto02-aw.eurocontrol.fr> References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> <20130828022728.GR29777@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130828022728.GR29777@funkthat.com> X-Operating-System: MacOS X / Macbook Pro - FreeBSD 7.2 / Dell D820 SMP User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 09:18:15 -0000 According to John-Mark Gurney on Tue, Aug 27, 2013 at 07:27:28PM -0700: > I guess now we need to figure out how to teach OpenSSL to use AES-NI > natively even when /dev/crypto is available... > > but at least we did solve the (non-)issue of bad OpenSSL performance... Excellent analysis, thank you. I must admit it is not always easy to see how openssl works, it is a bit, ahem, messy around there :) > I will submit a patch to OpenSSL to not make the documentation of the > -elapsed option dependent on defines... Thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 05:19:19 2013 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E7FAB314 for ; Wed, 28 Aug 2013 05:19:19 +0000 (UTC) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Received: from nskntmtas03p.mx.bigpond.com (nskntmtas03p.mx.bigpond.com [61.9.168.143]) by mx1.freebsd.org (Postfix) with ESMTP id 84E612AB8 for ; Wed, 28 Aug 2013 05:19:19 +0000 (UTC) Received: from nskntcmgw09p ([61.9.169.169]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20130828051912.BAOK1983.nskntmtas03p.mx.bigpond.com@nskntcmgw09p>; Wed, 28 Aug 2013 05:19:12 +0000 Received: from hermes.heuristicsystems.com.au ([58.172.113.247]) by nskntcmgw09p with BigPond Outbound id J5KB1m00N5LKYmq015KBpF; Wed, 28 Aug 2013 05:19:12 +0000 X-Authority-Analysis: v=2.0 cv=APSpfbFe c=1 sm=1 a=YibVxx38Z+cwdCKSMcELyg==:17 a=gtMxIXxmAI4A:10 a=twTT4oUKOlYA:10 a=kj9zAlcOel0A:10 a=GHIR_BbyAAAA:8 a=zj7oWWcsScEA:10 a=dOwBb8GsjfbD2fuA2ZwA:9 a=CjuIK1q_8ugA:10 a=g-8GH8jFSXgA:10 a=uELCwYtBvEgA:10 a=YibVxx38Z+cwdCKSMcELyg==:117 Received: from white (white.hs [10.0.5.2]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id r7S5Ih1S019690; Wed, 28 Aug 2013 15:18:43 +1000 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) From: "Dewayne Geraghty" To: "'John-Mark Gurney'" , "'Ollivier Robert'" References: <20130827153205.GA48196@roberto02-aw.eurocontrol.fr> <20130828022728.GR29777@funkthat.com> Subject: RE: security/openssl speed issues Date: Wed, 28 Aug 2013 15:18:43 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20130828022728.GR29777@funkthat.com> Thread-Index: Ac6jljr2hiVn5VVBT8KumsoyVknLvQAD0Rkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Mailman-Approved-At: Wed, 28 Aug 2013 11:22:11 +0000 Cc: freebsd-security@freebsd.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 05:19:20 -0000 John,Ollivier, I've found the openssl speed tests to be an unreliable measure of comparison. I think you might be better served by comparing the performance of encrypting/decrypting content, such as dd if=/dev/zero bs=1M count=100 | openssl aes-128-cbc -e -pass pass:secretpwd | \ openssl aes-128-cbc -d -pass pass:secretpwd >> /dev/null And for a baseline use dd if=/dev/zero bs=1M count=100 >> /dev/null Kind regards, Dewayne From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 12:10:38 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 10A20A9F; Wed, 28 Aug 2013 12:10:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id D5E18222C; Wed, 28 Aug 2013 12:10:32 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA08882; Wed, 28 Aug 2013 15:10:30 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEeZy-000OS2-7U; Wed, 28 Aug 2013 15:10:30 +0300 Message-ID: <521DE891.9070107@FreeBSD.org> Date: Wed, 28 Aug 2013 15:09:53 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org, freebsd-gnome@FreeBSD.org Subject: Re: [kde-freebsd] virtualbox file dialog problem References: <51E6B030.1080009@FreeBSD.org> <51E793DB.2020607@FreeBSD.org> In-Reply-To: <51E793DB.2020607@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Aug 2013 12:18:57 +0000 Cc: Greg Rivers , freebsd-standards@FreeBSD.org, kde@FreeBSD.org, freebsd-security@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 12:10:38 -0000 on 18/07/2013 10:06 Andriy Gapon said the following: > on 18/07/2013 03:25 Greg Rivers said the following: >> On Wed, 17 Jul 2013, Andriy Gapon wrote: >> >>> I run virtualbox in KDE environment. A while ago (can't say exactly when) I >>> started to have a problem where any file opening dialog would fail with this >>> message: "Cannot talk to klauncher: Not connected to D-Bus server" >>> >>> I found that setting KDE_FORK_SLAVES=1 in environment works around the problem. >> >> I reported this same problem in this[1] thread on freebsd-ports@. In that post >> I provided a link to a similar report for KDE on openSUSE that required a dbus >> patch to fix. >> >> I'm guessing that either the latest versions of VirtualBox have a bug in their >> dbus interface, or the version of dbus we have needs to be updated. >> >> [1] http://lists.freebsd.org/pipermail/freebsd-ports/2013-July/084783.html > > I saw those OpenSUSE reports but I think that they were against the much older > version of dbus. I have done some more investigation and the problems turns out to be dbus related indeed. The problem has only a tangential relation to KDE, so I plan to drop kde@ from this thread. It has a relation to what VirtualBox does, so I am keeping emulation@. It is related to dbus and gnome@ is its maintainer(s). It is also related to how issetugid(2) works, so I am including standards@, security@ and hackers@. So, please excuse me for such a wide distribution list, but I think that the solution should be negotiated among the parties involved. Now a description of the problem. 1. VirtualBox executable is installed setuid root. Apparently, when it is run it does some privileged things and then drops all of the uids and gids (real, effective and saved) back to what they should have been originally. VirtualBox does not do any (re-)exec of itself after the above manipulations. 2. issetugid(2) (which is apparently a BSD extension) on FreeBSD does not consider the above manipulations as sufficient to mark an executable as untainted. So it would return 1 for the VirtualBox process. 3. dbus code seems to impose some limitations on communication by such "tainted" processes. It has the following code: http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c#n4139 For web-impaired :) the gist is that on BSD systems the code uses issetugid but on other systems (like Linux) it uses getresuid and getresgid and checks that all 3 uids are the same and all 3 gids are the same. As a result, on FreeBSD the dbus code would consider the VirtualBox process tainted and that impairs its communication with KDE components. On systems without issetugid or those that implement it differently, dbus would work as for a normal process and all the communications are OK. I've also verified this conclusion by forcing dbus to use the alternative logic on FreeBSD. So, possible solutions: A. change how issetugid(2) works on FreeBSD; a comment in sys_issetugid hints that other BSDs may have different behaviors B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself after dropping the privileges C. patch dbus port to not use issetugid(2) D. something else What do you guys think? -- Andriy Gapon From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 12:24:29 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C3749E1; Wed, 28 Aug 2013 12:24:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 59B962368; Wed, 28 Aug 2013 12:24:28 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA09014; Wed, 28 Aug 2013 15:24:26 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VEenS-000OTH-Fs; Wed, 28 Aug 2013 15:24:26 +0300 Message-ID: <521DEBC2.1080602@FreeBSD.org> Date: Wed, 28 Aug 2013 15:23:30 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130810 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-emulation@FreeBSD.org Subject: Re: [kde-freebsd] virtualbox file dialog problem References: <51E6B030.1080009@FreeBSD.org> <51E793DB.2020607@FreeBSD.org> <521DE891.9070107@FreeBSD.org> In-Reply-To: <521DE891.9070107@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 28 Aug 2013 12:48:58 +0000 Cc: freebsd-hackers@FreeBSD.org, freebsd-standards@FreeBSD.org, freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 12:24:29 -0000 on 28/08/2013 15:09 Andriy Gapon said the following: > Now a description of the problem. > > 1. VirtualBox executable is installed setuid root. Apparently, when it is run > it does some privileged things and then drops all of the uids and gids (real, > effective and saved) back to what they should have been originally. > VirtualBox does not do any (re-)exec of itself after the above manipulations. > > 2. issetugid(2) (which is apparently a BSD extension) on FreeBSD does not > consider the above manipulations as sufficient to mark an executable as > untainted. So it would return 1 for the VirtualBox process. > > 3. dbus code seems to impose some limitations on communication by such "tainted" > processes. It has the following code: > http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c#n4139 > For web-impaired :) the gist is that on BSD systems the code uses issetugid but > on other systems (like Linux) it uses getresuid and getresgid and checks that > all 3 uids are the same and all 3 gids are the same. > > As a result, on FreeBSD the dbus code would consider the VirtualBox process > tainted and that impairs its communication with KDE components. > On systems without issetugid or those that implement it differently, dbus would > work as for a normal process and all the communications are OK. > > I've also verified this conclusion by forcing dbus to use the alternative logic > on FreeBSD. > > So, possible solutions: [snip] > B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself > after dropping the privileges [snip] BTW, I've just found this "interesting" code in the VirtualBox sources (forgive me a full paste, but I couldn't resist): #if defined(RT_OS_DARWIN) # include # include # include # include /** Really ugly hack to shut up a silly check in AppKit. */ static void ShutUpAppKit(void) { /* Check for Snow Leopard or higher */ char szInfo[64]; int rc = RTSystemQueryOSInfo (RTSYSOSINFO_RELEASE, szInfo, sizeof(szInfo)); if ( RT_SUCCESS (rc) && szInfo[0] == '1') /* higher than 1x.x.x */ { /* * Find issetguid() and make it always return 0 by modifying the code. */ void *addr = dlsym(RTLD_DEFAULT, "issetugid"); int rc = mprotect((void *)((uintptr_t)addr & ~(uintptr_t)0xfff), 0x2000, PROT_WRITE|PROT_READ|PROT_EXEC); if (!rc) ASMAtomicWriteU32((volatile uint32_t *)addr, 0xccc3c031); /* xor eax, eax; ret; int3 */ } } #endif /* DARWIN */ -- Andriy Gapon From owner-freebsd-security@FreeBSD.ORG Wed Aug 28 22:13:20 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 794C963B; Wed, 28 Aug 2013 22:13:20 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 207F62BB4; Wed, 28 Aug 2013 22:13:20 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 3CDF9120207; Thu, 29 Aug 2013 00:13:04 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 20BF828494; Thu, 29 Aug 2013 00:13:04 +0200 (CEST) Date: Thu, 29 Aug 2013 00:13:04 +0200 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: [kde-freebsd] virtualbox file dialog problem Message-ID: <20130828221303.GA53931@stack.nl> References: <51E6B030.1080009@FreeBSD.org> <51E793DB.2020607@FreeBSD.org> <521DE891.9070107@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <521DE891.9070107@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Greg Rivers , kde@FreeBSD.org, freebsd-gnome@FreeBSD.org, freebsd-hackers@FreeBSD.org, freebsd-security@FreeBSD.org, freebsd-emulation@FreeBSD.org, freebsd-standards@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Aug 2013 22:13:20 -0000 On Wed, Aug 28, 2013 at 03:09:53PM +0300, Andriy Gapon wrote: > on 18/07/2013 10:06 Andriy Gapon said the following: > > on 18/07/2013 03:25 Greg Rivers said the following: > >> On Wed, 17 Jul 2013, Andriy Gapon wrote: > >>> I run virtualbox in KDE environment. A while ago (can't say > >>> exactly when) I started to have a problem where any file opening > >>> dialog would fail with this message: "Cannot talk to klauncher: > >>> Not connected to D-Bus server" > >>> > >>> I found that setting KDE_FORK_SLAVES=1 in environment works around > >>> the problem. > >> > >> I reported this same problem in this[1] thread on freebsd-ports@. > >> In that post I provided a link to a similar report for KDE on > >> openSUSE that required a dbus patch to fix. > >> I'm guessing that either the latest versions of VirtualBox have a > >> bug in their dbus interface, or the version of dbus we have needs > >> to be updated. > >> [1] http://lists.freebsd.org/pipermail/freebsd-ports/2013-July/084783.html > > I saw those OpenSUSE reports but I think that they were against the > > much older version of dbus. > I have done some more investigation and the problems turns out to be dbus > related indeed. > The problem has only a tangential relation to KDE, so I plan to drop > kde@ from this thread. It has a relation to what VirtualBox does, so > I am keeping emulation@. It is related to dbus and gnome@ is its > maintainer(s). It is also related to how issetugid(2) works, so I am > including standards@, security@ and hackers@. So, please excuse me for > such a wide distribution list, but I think that the solution should be > negotiated among the parties involved. > Now a description of the problem. > 1. VirtualBox executable is installed setuid root. Apparently, when > it is run it does some privileged things and then drops all of the > uids and gids (real, effective and saved) back to what they should > have been originally. VirtualBox does not do any (re-)exec of itself > after the above manipulations. > 2. issetugid(2) (which is apparently a BSD extension) on FreeBSD does > not consider the above manipulations as sufficient to mark an > executable as untainted. So it would return 1 for the VirtualBox > process. The manipulations do not guarantee that all privileged information and descriptors are no longer in the process. Often, a process will acquire some privileged resource and then drop to user credentials; for example, a raw socket in ping(8). Also, calls like getpwuid() might leave privileged information in memory. > 3. dbus code seems to impose some limitations on communication by such > "tainted" processes. It has the following code: > http://cgit.freedesktop.org/dbus/dbus/tree/dbus/dbus-sysdeps-unix.c#n4139 > For web-impaired :) the gist is that on BSD systems the code uses > issetugid but on other systems (like Linux) it uses getresuid and > getresgid and checks that all 3 uids are the same and all 3 gids are > the same. > As a result, on FreeBSD the dbus code would consider the VirtualBox > process tainted and that impairs its communication with KDE > components. On systems without issetugid or those that implement it > differently, dbus would work as for a normal process and all the > communications are OK. > I've also verified this conclusion by forcing dbus to use the > alternative logic on FreeBSD. I think dbus is doing the right thing on BSD and the getresuid/getresgid-based check on Linux is a bug. This bug was reported on https://bugs.freedesktop.org/show_bug.cgi?id=52202 however it was decided not to fix the bug because gnome-keyring-daemon relies on it. The gnome-keyring-daemon obtains cap_ipc_lock privilege (capability in Linux terms) from the filesystem and needs untrusted environment variables to work. (Note that this also means that moving a program from setuid root to capabilities may decrease security, since dbus and glib no longer know to be careful.) > So, possible solutions: > A. change how issetugid(2) works on FreeBSD; a comment in > sys_issetugid hints that other BSDs may have different behaviors I think it works correctly. By the way, issetugid(2) man page appears a bit too focused on UIDs/GIDs. The implementation also sets the bit (and rightly so) if MAC causes a transition on execve(2) or if jail_attach(2) is called. > B. change VirtualBox to be friendly to FreeBSD issetugid(2) and exec itself > after dropping the privileges This would be good, but it may need invasive changes to VirtualBox that its developers do not want to make. > C. patch dbus port to not use issetugid(2) This may open up security holes. > D. something else Two ideas. Firstly, a hack in VirtualBox that subverts issetugid() or _dbus_check_setuid() somehow may be appropriate. This does not require invasive changes to VirtualBox, and if you want a secure system you do not install VirtualBox anyway. This subversion could be done by overwriting the code of issetugid() or by inserting a dummy implementation of issetugid() with FBSD_1.0 version before libc.so in the lookup order, for example. Secondly, if setting KDE_FORK_SLAVES=1 works around the problem, perhaps KDE should behave that way automatically if it is called from a process with issetugid() true. -- Jilles Tjoelker From owner-freebsd-security@FreeBSD.ORG Thu Aug 29 00:46:39 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AC85AC83 for ; Thu, 29 Aug 2013 00:46:39 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6CDCC24AA for ; Thu, 29 Aug 2013 00:46:39 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VEqPk-000IQZ-AQ for freebsd-security@FreeBSD.org; Thu, 29 Aug 2013 04:48:44 +0400 Date: Thu, 29 Aug 2013 04:48:44 +0400 From: Slawa Olhovchenkov To: freebsd-security@FreeBSD.org Subject: OpenSSH, PAM and kerberos Message-ID: <20130829004844.GA70584@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 00:46:39 -0000 I am try to setup single sign-on and found this is imposuble due to bug in OpenSSH: currently sshd do pam_authenticate() and pam_acct_mgmt() from child process, but pam_setcred() from paren proccess. pam_krb5 in pam_sm_setcred() required information from pam_sm_authenticate and can't work corretly (can't create /tmp/krb5cc_NNNN, can't set envirompent KRB5CCNAME and so). In logs/debugs this is as openpam_dispatch(): pam_krb5.so: pam_sm_setcred(): failed to retrieve user credentials From owner-freebsd-security@FreeBSD.ORG Thu Aug 29 11:14:59 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CD9D0361 for ; Thu, 29 Aug 2013 11:14:59 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8C4BF2CEC for ; Thu, 29 Aug 2013 11:14:59 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VF0Dn-0001TI-E6; Thu, 29 Aug 2013 15:17:03 +0400 Date: Thu, 29 Aug 2013 15:17:03 +0400 From: Slawa Olhovchenkov To: freebsd-security@FreeBSD.org Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130829111703.GB3371@zxy.spb.ru> References: <20130829004844.GA70584@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130829004844.GA70584@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: des@des.no X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2013 11:14:59 -0000 On Thu, Aug 29, 2013 at 04:48:44AM +0400, Slawa Olhovchenkov wrote: > I am try to setup single sign-on and found this is imposuble due to > bug in OpenSSH: currently sshd do pam_authenticate() and > pam_acct_mgmt() from child process, but pam_setcred() from paren > proccess. pam_krb5 in pam_sm_setcred() required information from > pam_sm_authenticate and can't work corretly (can't create > /tmp/krb5cc_NNNN, can't set envirompent KRB5CCNAME and so). > > In logs/debugs this is as > > openpam_dispatch(): pam_krb5.so: pam_sm_setcred(): failed to retrieve user credentials As I see, similar bug open in upstream from 2003: https://bugzilla.mindrot.org/show_bug.cgi?id=688 From owner-freebsd-security@FreeBSD.ORG Fri Aug 30 07:45:29 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 17818E39 for ; Fri, 30 Aug 2013 07:45:29 +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 D04DC2DE7 for ; Fri, 30 Aug 2013 07:45:28 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id C4EE24CAF; Fri, 30 Aug 2013 07:45:27 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 21B1F29CC6; Fri, 30 Aug 2013 09:44:54 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Slawa Olhovchenkov Subject: Re: OpenSSH, PAM and kerberos References: <20130829004844.GA70584@zxy.spb.ru> Date: Fri, 30 Aug 2013 09:44:54 +0200 In-Reply-To: <20130829004844.GA70584@zxy.spb.ru> (Slawa Olhovchenkov's message of "Thu, 29 Aug 2013 04:48:44 +0400") Message-ID: <86d2ovy64p.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 07:45:29 -0000 Slawa Olhovchenkov writes: > I am try to setup single sign-on and found this is imposuble due to > bug in OpenSSH: currently sshd do pam_authenticate() and > pam_acct_mgmt() from child process, but pam_setcred() from paren > proccess. pam_krb5 in pam_sm_setcred() required information from > pam_sm_authenticate and can't work corretly (can't create > /tmp/krb5cc_NNNN, can't set envirompent KRB5CCNAME and so). PAM authentication in OpenSSH was broken for non-trivial cases when privilege separation was implemented. Fixing it properly would be very difficult. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Aug 30 10:07:21 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E4C78A21 for ; Fri, 30 Aug 2013 10:07:21 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0612793 for ; Fri, 30 Aug 2013 10:07:21 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFLdu-0000bb-7F; Fri, 30 Aug 2013 14:09:26 +0400 Date: Fri, 30 Aug 2013 14:09:26 +0400 From: Slawa Olhovchenkov To: Dag-Erling Sm??rgrav Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130830100926.GU3796@zxy.spb.ru> References: <20130829004844.GA70584@zxy.spb.ru> <86d2ovy64p.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86d2ovy64p.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 10:07:22 -0000 On Fri, Aug 30, 2013 at 09:44:54AM +0200, Dag-Erling Sm??rgrav wrote: > Slawa Olhovchenkov writes: > > I am try to setup single sign-on and found this is imposuble due to > > bug in OpenSSH: currently sshd do pam_authenticate() and > > pam_acct_mgmt() from child process, but pam_setcred() from paren > > proccess. pam_krb5 in pam_sm_setcred() required information from > > pam_sm_authenticate and can't work corretly (can't create > > /tmp/krb5cc_NNNN, can't set envirompent KRB5CCNAME and so). > > PAM authentication in OpenSSH was broken for non-trivial cases when > privilege separation was implemented. Fixing it properly would be very > difficult. Same behaviour with 'UsePrivilegeSeparation no'. From owner-freebsd-security@FreeBSD.ORG Fri Aug 30 10:28:03 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E5433F71 for ; Fri, 30 Aug 2013 10:28:03 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0EA28E4 for ; Fri, 30 Aug 2013 10:28:03 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFLxx-0000lc-1k; Fri, 30 Aug 2013 14:30:09 +0400 Date: Fri, 30 Aug 2013 14:30:09 +0400 From: Slawa Olhovchenkov To: Dag-Erling Sm??rgrav Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130830103009.GV3796@zxy.spb.ru> References: <20130829004844.GA70584@zxy.spb.ru> <86d2ovy64p.fsf@nine.des.no> <20130830100926.GU3796@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130830100926.GU3796@zxy.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 10:28:04 -0000 On Fri, Aug 30, 2013 at 02:09:26PM +0400, Slawa Olhovchenkov wrote: > On Fri, Aug 30, 2013 at 09:44:54AM +0200, Dag-Erling Sm??rgrav wrote: > > > Slawa Olhovchenkov writes: > > > I am try to setup single sign-on and found this is imposuble due to > > > bug in OpenSSH: currently sshd do pam_authenticate() and > > > pam_acct_mgmt() from child process, but pam_setcred() from paren > > > proccess. pam_krb5 in pam_sm_setcred() required information from > > > pam_sm_authenticate and can't work corretly (can't create > > > /tmp/krb5cc_NNNN, can't set envirompent KRB5CCNAME and so). > > > > PAM authentication in OpenSSH was broken for non-trivial cases when > > privilege separation was implemented. Fixing it properly would be very > > difficult. > > Same behaviour with 'UsePrivilegeSeparation no'. > This issuse not in privilege separation, this is because PAM authentication use pthread emulation throw fork(). From owner-freebsd-security@FreeBSD.ORG Fri Aug 30 12:51:49 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F4AD12A for ; Fri, 30 Aug 2013 12:51:49 +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 0352021E3 for ; Fri, 30 Aug 2013 12:51:48 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 1A57D409B; Fri, 30 Aug 2013 12:51:48 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 869EF29D25; Fri, 30 Aug 2013 14:51:44 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Slawa Olhovchenkov Subject: Re: OpenSSH, PAM and kerberos References: <20130829004844.GA70584@zxy.spb.ru> <86d2ovy64p.fsf@nine.des.no> <20130830100926.GU3796@zxy.spb.ru> <20130830103009.GV3796@zxy.spb.ru> Date: Fri, 30 Aug 2013 14:51:44 +0200 In-Reply-To: <20130830103009.GV3796@zxy.spb.ru> (Slawa Olhovchenkov's message of "Fri, 30 Aug 2013 14:30:09 +0400") Message-ID: <86sixrwdcv.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 12:51:49 -0000 Slawa Olhovchenkov writes: > Dag-Erling Sm=C3=B8rgrav writes: > > PAM authentication in OpenSSH was broken for non-trivial cases when > > privilege separation was implemented. Fixing it properly would be > > very difficult. > Same behaviour with 'UsePrivilegeSeparation no'. This issuse not in > privilege separation, this is because PAM authentication use pthread > emulation throw fork(). Please don't tell me how the code works. I wrote it - or rather, I wrote a version that worked, before the OpenSSH developers implemented privilege separation and had to break the PAM integration code to make it fit. Even if you #define UNSUPPORTED_POSIX_THREADS_HACK to use threads instead of a subprocess, OpenSSH will still call pam_start() twice and lose the data stored in the authentication phase before running the session phase. (this is technically an abuse of the PAM API; I should probably add a few lines to the OpenPAM dispatcher so it logs an error every time an application tries to open a session without first authenticating) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Aug 30 13:12:51 2013 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9D747E39 for ; Fri, 30 Aug 2013 13:12:51 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 570EB2378 for ; Fri, 30 Aug 2013 13:12:51 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1VFOXP-0002Hm-St; Fri, 30 Aug 2013 17:14:55 +0400 Date: Fri, 30 Aug 2013 17:14:55 +0400 From: Slawa Olhovchenkov To: Dag-Erling Sm??rgrav Subject: Re: OpenSSH, PAM and kerberos Message-ID: <20130830131455.GW3796@zxy.spb.ru> References: <20130829004844.GA70584@zxy.spb.ru> <86d2ovy64p.fsf@nine.des.no> <20130830100926.GU3796@zxy.spb.ru> <20130830103009.GV3796@zxy.spb.ru> <86sixrwdcv.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86sixrwdcv.fsf@nine.des.no> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: freebsd-security@FreeBSD.org X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 13:12:51 -0000 On Fri, Aug 30, 2013 at 02:51:44PM +0200, Dag-Erling Sm??rgrav wrote: > Slawa Olhovchenkov writes: > > Dag-Erling Sm??rgrav writes: > > > PAM authentication in OpenSSH was broken for non-trivial cases when > > > privilege separation was implemented. Fixing it properly would be > > > very difficult. > > Same behaviour with 'UsePrivilegeSeparation no'. This issuse not in > > privilege separation, this is because PAM authentication use pthread > > emulation throw fork(). > > Please don't tell me how the code works. I wrote it - or rather, I > wrote a version that worked, before the OpenSSH developers implemented > privilege separation and had to break the PAM integration code to make > it fit. Even if you #define UNSUPPORTED_POSIX_THREADS_HACK to use > threads instead of a subprocess, OpenSSH will still call pam_start() > twice and lose the data stored in the authentication phase before > running the session phase. Hmmm, now I try to compile sshd with UNSUPPORTED_POSIX_THREADS_HACK and it works (/tmp/krb5cc_NNNN created, kerberosied login to other host working w/o entering password). And I see only one record in log file (debug1: PAM: initializing for "slw") What I missed? PS: UsePrivilegeSeparation yes > (this is technically an abuse of the PAM API; I should probably add a > few lines to the OpenPAM dispatcher so it logs an error every time an > application tries to open a session without first authenticating) > > DES > -- > Dag-Erling Sm??rgrav - des@des.no