Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp1275477pxk; Thu, 10 Sep 2020 11:15:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzQ4uDlBWXQe/ti+Q8eIQvFbTwpJ0+t9q/9fA8/jsjU4Mc/QaHAtFuxjsl1A7aREHf7cU7 X-Received: by 2002:a17:906:556:: with SMTP id k22mr9942190eja.369.1599761714801; Thu, 10 Sep 2020 11:15:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599761714; cv=none; d=google.com; s=arc-20160816; b=Ga1SVV0UhoP2fGWo6en4dIhG1qp4A/4yZH7idSeq62n3zx1qPE6pEfTVIhVw9z+cjY wsfNIeK49fpHoLexqFNeMMqv4+P4TrtQ4zEOqUHz9WhoWYBYegU3U/+sagPVU6WZPVLd KmVAp4oFrmpeEw15zka8IhV9vq2Cdcgy250xYZM8RSzyd6/g1XYqltpd+eCQeLgQAj0w i7EJ2dw7/heEkuEWoogy90uksb1/CtHi+ffffIYJLqq/1BaMWUjN4TvSDJY/3/6AXqy+ oY/wvHqzaQ+0lt7RycJgeURFsnm9qrrdJTLspLShUzqyGJBpIvxKp36lGv25psoqqeuw 8CTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature; bh=FjhvSZCWrVc2GuEefwPTWWMXiO1Vz/54oCDqSvjTAUA=; b=mPoXNNNTDPBuN2aMpC3Q7rZSJ5d1dUZIgjJh+jHCC7sQgmO8eDqy3cLJfi7INKAcwV iAgIg3/HwraoMHnr5mY8OZVpC/0Ou+L8cKaE2Jax+2mNGTNBWEaMdGcDMid24Zg+fSgu MLQnNlrtvk405CxJcaobnZZ3Dpyol5bmptsQMIbA4ursT+e1dqrKM8SAG4OqS4hPkU/4 benso4Ao+DypcTiiDOwIOFnn/KR7y/SSCSYDIbKCQIyPZTzIKYyfLevh0bep5I1IL0gn 72yq52waJE+n6l42uB1IZ0SqDHMMhWw91rM+cuan/qHI1V/UbcuWUWLhT/SA8KXO+k/X dstw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=jvZvaNyI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r22si4143109edv.388.2020.09.10.11.14.52; Thu, 10 Sep 2020 11:15:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=jvZvaNyI; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726384AbgIJSMA (ORCPT + 99 others); Thu, 10 Sep 2020 14:12:00 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:6594 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726676AbgIJSK2 (ORCPT ); Thu, 10 Sep 2020 14:10:28 -0400 Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 08AI3eiS035469; Thu, 10 Sep 2020 14:09:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : subject : from : to : cc : date : in-reply-to : references : content-type : mime-version : content-transfer-encoding; s=pp1; bh=FjhvSZCWrVc2GuEefwPTWWMXiO1Vz/54oCDqSvjTAUA=; b=jvZvaNyI3D6ck4Vz/wLNL+BUdL6il13Jzma6dPEMLvd9/QeiVtmpYZ9G2BDJrKoa2Pf3 qDWxD3uxUvazXL5StzKj+/VPK+8VP5hSyc4Nv+4kFBeg+6Zm2EOWIXcxoxQXJnmGvw8y jhPs1RbJ58LPa1GITBKDVer6VbPxzVaBegxACm6xawR3UOrN6+2imVMI+fdWQkm2zPkv eRWfpMBze4Fb3hhffadOi1lgnJVFga96Emvwi14G4SFbGe2923+2ROTZZF365Cl1HpIC yx+QplZfITiq781JYwgyvt/h8Gcs6H4yoTwqCi8Aq3fNrMnl6/WBKpqE9JIXX8CEdvDr Zg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 33frc6hgmk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 14:09:10 -0400 Received: from m0098414.ppops.net (m0098414.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 08AI4aDF038208; Thu, 10 Sep 2020 14:09:10 -0400 Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0b-001b2d01.pphosted.com with ESMTP id 33frc6hgk7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 14:09:09 -0400 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 08AI97tB003145; Thu, 10 Sep 2020 18:09:07 GMT Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by ppma04fra.de.ibm.com with ESMTP id 33f91w8gmt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 18:09:07 +0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 08AI95de33948012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 10 Sep 2020 18:09:05 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2130B4C046; Thu, 10 Sep 2020 18:09:05 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9D3B84C040; Thu, 10 Sep 2020 18:08:57 +0000 (GMT) Received: from sig-9-65-238-209.ibm.com (unknown [9.65.238.209]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Thu, 10 Sep 2020 18:08:57 +0000 (GMT) Message-ID: Subject: Re: [RFC PATCH v9 0/3] Add introspect_access(2) (was O_MAYEXEC) From: Mimi Zohar To: =?ISO-8859-1?Q?Micka=EBl_Sala=FCn?= , Matthew Wilcox Cc: linux-kernel@vger.kernel.org, Aleksa Sarai , Alexei Starovoitov , Al Viro , Andrew Morton , Andy Lutomirski , Arnd Bergmann , Casey Schaufler , Christian Brauner , Christian Heimes , Daniel Borkmann , Deven Bowers , Dmitry Vyukov , Eric Biggers , Eric Chiang , Florian Weimer , James Morris , Jan Kara , Jann Horn , Jonathan Corbet , Kees Cook , Lakshmi Ramasubramanian , Matthew Garrett , Michael Kerrisk , Miklos Szeredi , Philippe =?ISO-8859-1?Q?Tr=E9buchet?= , Scott Shell , Sean Christopherson , Shuah Khan , Steve Dower , Steve Grubb , Tetsuo Handa , Thibaut Sautereau , Vincent Strubel , kernel-hardening@lists.openwall.com, linux-api@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org Date: Thu, 10 Sep 2020 14:08:56 -0400 In-Reply-To: References: <20200910164612.114215-1-mic@digikod.net> <20200910170424.GU6583@casper.infradead.org> Content-Type: text/plain; charset="ISO-8859-15" X-Mailer: Evolution 3.28.5 (3.28.5-12.el8) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-10_05:2020-09-10,2020-09-10 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 spamscore=0 malwarescore=0 priorityscore=1501 suspectscore=3 mlxlogscore=999 clxscore=1011 adultscore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009100162 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2020-09-10 at 19:21 +0200, Micka?l Sala?n wrote: > On 10/09/2020 19:04, Matthew Wilcox wrote: > > On Thu, Sep 10, 2020 at 06:46:09PM +0200, Micka?l Sala?n wrote: > >> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC > >> series with a new syscall: introspect_access(2) . Access check are now > >> only possible on a file descriptor, which enable to avoid possible race > >> conditions in user space. > > > > But introspection is about examining _yourself_. This isn't about > > doing that. It's about doing ... something ... to a script that you're > > going to execute. If the script were going to call the syscall, then > > it might be introspection. Or if the interpreter were measuring itself, > > that would be introspection. But neither of those would be useful things > > to do, because an attacker could simply avoid doing them. > Michael, is the confusion here that IMA isn't measuring anything, but verifying the integrity of the file? The usecase, from an IMA perspective, is enforcing a system wide policy requiring everything executed to be signed. In this particular use case, the interpreter is asking the kernel if the script is signed with a permitted key. The signature may be an IMA signature or an EVM portable and immutable signature, based on policy. > Picking a good name other than "access" (or faccessat2) is not easy. The > idea with introspect_access() is for the calling task to ask the kernel > if this task should allows to do give access to a kernel resource which > is already available to this task. In this sense, we think that > introspection makes sense because it is the choice of the task to allow > or deny an access. > > > > > So, bad name. What might be better? sys_security_check()? > > sys_measure()? sys_verify_fd()? I don't know. > > > > "security_check" looks quite broad, "measure" doesn't make sense here, > "verify_fd" doesn't reflect that it is an access check. Yes, not easy, > but if this is the only concern we are on the good track. :) Maybe replacing the term "measure" with "integrity", but rather than "integrity_check", something along the lines of fgetintegrity, freadintegrity, fcheckintegrity. Mimi > > > Other ideas: > - interpret_access (mainly, but not only, for interpreters) > - indirect_access > - may_access > - faccessat3