From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S968532AbdAET4G (ORCPT ); Thu, 5 Jan 2017 14:56:06 -0500 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57051 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757318AbdAETz5 (ORCPT ); Thu, 5 Jan 2017 14:55:57 -0500 Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager From: James Bottomley To: Jason Gunthorpe Cc: "tpmdd-devel@lists.sourceforge.net" , "linux-security-module@vger.kernel.org" , open list Date: Thu, 05 Jan 2017 11:55:49 -0800 In-Reply-To: <20170105192025.GB12587@obsidianresearch.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <9F48E1A823B03B4790B7E6E69430724DC7C149F6@exch2010c.sit.fraunhofer.de> <20170105172726.GA11680@obsidianresearch.com> <1483641223.2515.62.camel@linux.vnet.ibm.com> <20170105192025.GB12587@obsidianresearch.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17010519-0016-0000-0000-00000591E2EB X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006379; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000199; SDB=6.00804018; UDB=6.00391211; IPR=6.00581865; BA=6.00005031; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013835; XFM=3.00000011; UTC=2017-01-05 19:55:55 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17010519-0017-0000-0000-00003605BC98 Message-Id: <1483646149.2515.83.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-01-05_14:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701050293 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-01-05 at 12:20 -0700, Jason Gunthorpe wrote: > On Thu, Jan 05, 2017 at 10:33:43AM -0800, James Bottomley wrote: > > > > A combo ioctl that could setup the session, issue an operation in > > > it > > > and then delete the session, for instance. > > > > This would work for encryption or HMAC sessions, but probably not > > for policy sessions, because they can have an arbitrarily large > > command sequence to construct them. > > I'd rather give up features (eg policy sessions, if necessary) for > the unpriv fd than give up security of the unpriv fd. We don't really have that choice: Keys require authorization, so you have to have an auth session. If you want things like PCR sealed or time limited keys, you don't really have a choice on policy sessions either. I think we've got to the point where arguing about our divergent use requirements shows the default should be 0600 and every command enabled so that whatever changes the device to 0666 also applies the command filter policy. It's the fully safe default that satisfies everyone. Once you have the command blacklist, you can blacklist every policy command before you make your device 0666. That effecively achieves what you want because no-one can now initiate a policy session. > We always have the out that special stuff can go down the priv path. > > > The other issue we're likely to run into if we do it this way is > > delayed error reporting. > > Not sure I follow. If we try to issue a load of commands as a transaction, you only get the error when the transaction is executed, even if the entity causing the problem is way back in the command sequence. > > How about a more traditional approach which would be leasing > > (basically what we use for NFS). Any application opening a session > > would have > > Doesn't this just change the DOS vector? Now the attacker has to > delay execution of TPM commands long enough to force session leases > to time out. That isn't too hard to do, asking the TPM to make a RSA > key can take seconds, for instance. I really don't think we can prevent all types of DoS in the TPM. After all, in a lot of current silicon, it can take up to 90 seconds to generate an RSA key using the KDF ... the TPM is unavailable while this is happening, so there's your DoS on a standard command. What we need to aim for is effective resource sharing. The 64 handle limit is one of the nasty ones that a bunch of applications could accidentally overflow. A lease model bounds the TPM blocked time while you're waiting for an available handle and coping with a lease timeout can be done in the TSS. TPM execution time could be added to lease expiry, so even if someone's doing a sequence of RSA KDFs, you eventually get your job executed as long as we do the execution of blocked commands in a strict order. In this model, you can "DoS" me by substantially delaying the execution of my commands, but you can't prevent it from executing within a bounded time. I suppose we could even make TPM execution time an RLIMIT. James From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [tpmdd-devel] [PATCH RFC 0/4] RFC: in-kernel resource manager Date: Thu, 05 Jan 2017 11:55:49 -0800 Message-ID: <1483646149.2515.83.camel@linux.vnet.ibm.com> References: <20170102132213.22880-1-jarkko.sakkinen@linux.intel.com> <9F48E1A823B03B4790B7E6E69430724DC7C149F6@exch2010c.sit.fraunhofer.de> <20170105172726.GA11680@obsidianresearch.com> <1483641223.2515.62.camel@linux.vnet.ibm.com> <20170105192025.GB12587@obsidianresearch.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20170105192025.GB12587@obsidianresearch.com> Sender: owner-linux-security-module@vger.kernel.org To: Jason Gunthorpe Cc: "tpmdd-devel@lists.sourceforge.net" , "linux-security-module@vger.kernel.org" , open list List-Id: tpmdd-devel@lists.sourceforge.net On Thu, 2017-01-05 at 12:20 -0700, Jason Gunthorpe wrote: > On Thu, Jan 05, 2017 at 10:33:43AM -0800, James Bottomley wrote: > > > > A combo ioctl that could setup the session, issue an operation in > > > it > > > and then delete the session, for instance. > > > > This would work for encryption or HMAC sessions, but probably not > > for policy sessions, because they can have an arbitrarily large > > command sequence to construct them. > > I'd rather give up features (eg policy sessions, if necessary) for > the unpriv fd than give up security of the unpriv fd. We don't really have that choice: Keys require authorization, so you have to have an auth session. If you want things like PCR sealed or time limited keys, you don't really have a choice on policy sessions either. I think we've got to the point where arguing about our divergent use requirements shows the default should be 0600 and every command enabled so that whatever changes the device to 0666 also applies the command filter policy. It's the fully safe default that satisfies everyone. Once you have the command blacklist, you can blacklist every policy command before you make your device 0666. That effecively achieves what you want because no-one can now initiate a policy session. > We always have the out that special stuff can go down the priv path. > > > The other issue we're likely to run into if we do it this way is > > delayed error reporting. > > Not sure I follow. If we try to issue a load of commands as a transaction, you only get the error when the transaction is executed, even if the entity causing the problem is way back in the command sequence. > > How about a more traditional approach which would be leasing > > (basically what we use for NFS). Any application opening a session > > would have > > Doesn't this just change the DOS vector? Now the attacker has to > delay execution of TPM commands long enough to force session leases > to time out. That isn't too hard to do, asking the TPM to make a RSA > key can take seconds, for instance. I really don't think we can prevent all types of DoS in the TPM. After all, in a lot of current silicon, it can take up to 90 seconds to generate an RSA key using the KDF ... the TPM is unavailable while this is happening, so there's your DoS on a standard command. What we need to aim for is effective resource sharing. The 64 handle limit is one of the nasty ones that a bunch of applications could accidentally overflow. A lease model bounds the TPM blocked time while you're waiting for an available handle and coping with a lease timeout can be done in the TSS. TPM execution time could be added to lease expiry, so even if someone's doing a sequence of RSA KDFs, you eventually get your job executed as long as we do the execution of blocked commands in a strict order. In this model, you can "DoS" me by substantially delaying the execution of my commands, but you can't prevent it from executing within a bounded time. I suppose we could even make TPM execution time an RLIMIT. James