From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751217AbdA3BFU (ORCPT ); Sun, 29 Jan 2017 20:05:20 -0500 Received: from [195.159.176.226] ([195.159.176.226]:43248 "EHLO blaine.gmane.org" rhost-flags-FAIL-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1750839AbdA3BFP (ORCPT ); Sun, 29 Jan 2017 20:05:15 -0500 X-Injected-Via-Gmane: http://gmane.org/ To: linux-kernel@vger.kernel.org From: Ken Goldman Subject: Re: [RFC] tpm2-space: add handling for global session exhaustion Date: Sun, 29 Jan 2017 19:52:20 -0500 Message-ID: References: <1484772489.2396.2.camel@HansenPartnership.com> <1485554699.3229.20.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 In-Reply-To: <1485554699.3229.20.camel@HansenPartnership.com> Cc: tpmdd-devel@lists.sourceforge.net, linux-security-module@vger.kernel.org Cc: tpmdd-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 1/27/2017 5:04 PM, James Bottomley wrote: >> Beware the nasty corner case: >> >> - Application asks for a session and gets 02000000 >> >> - Time elapses and 02000000 gets forcibly flushed >> >> - Later, app comes back, asks for a second session and again gets >> 02000000. >> >> - App gets very confused. >> >> May it be better to close the connection completely, which the >> application can detect, than flush a session and give this corner >> case? > > if I look at the code I've written, I don't know what the session > number is, I just save sessionHandle in a variable for later use (lets > say to v1). If I got the same session number returned at a later time > and placed it in v2, all I'd notice is that an authorization using v1 > would fail. I'm not averse to killing the entire connection but, > assuming you have fallback, it might be kinder simply to ensure that > the operations with the reclaimed session fail (which is what the code > currently does). My worry is that this session failure cannot be detected by the application. An HMAC failure could cause the app to tell a user that they entered the wrong password. Misleading. On the TPM, it could trigger the dictionary attack lockout. For a PIN index, it could consume a failure count. Killing a policy session that has e.g., a policy signed term could cause the application to go back to some external entity for another authorization signature. Let's go up to the stack. What's the attack? If we're worried about many simultaneous applications (wouldn't that be wonderful), why not just let startauthsession fail? The application can just retry periodically. Just allocate them in triples so there's no deadlock. If we're worried about a DoS attack, killing a session just helps the attacker. The attacker can create a few connections and spin on startauthsession, locking everyone out anyway. ~~ Also, let's remember that this is a rare application. Sessions are only needed for remote access (requiring encryption, HMAC or salt), or policy sessions. ~~ Should the code also reserve a session for the kernel? Mark it not kill'able?