Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5751452imu; Mon, 26 Nov 2018 04:53:23 -0800 (PST) X-Google-Smtp-Source: AFSGD/XpbcbAuozpmzzjfg9NfgSMt6ty2XKGnO0EHzcT7NVodtGbGteVyJ0wdUquhnkeN4IYhEkW X-Received: by 2002:a62:2c81:: with SMTP id s123mr24156411pfs.174.1543236803262; Mon, 26 Nov 2018 04:53:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543236803; cv=none; d=google.com; s=arc-20160816; b=zpU91FcehOn9ScQd/Ytc+ckNA0hGkAssf/sMLUruVTYQx8aJg6PnV9XdA4ziC8pmGm TwgACjJsTbE89A9Nr9Bm0TIiwH3F7qiG84nkihHopwTd8JbJg+UM1RZYeVoqaCFUK6yT ZJInXj9+f/xxE9QIZmf0wIXkU8c4yOmj9ckf+hZJ3gexErLuGv7MiL8P/DsBT9j9Q4CB Ju23LrE53DLKJ01odsyow1ri8h4QlZe2p3riPunJv34uDy9GNFMgZSE2FjqAfGx4JFGT tI4YefHlGkJv96DxGES5Mz8/E37MB8B22q9Wa2OZyH6L5LHu/EFBVuOXTq1xLsJVlow/ Ciiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:references:in-reply-to:date:cc:to:from:subject; bh=Qrvi34J6eBsWo/OY9sT6DvriNYpeE08bEtK/DBf3hGY=; b=VW+8pGNfT4E1wRMPkXq94Y4zMwiZEsPqVH74QFeImbTu9I6rR6ZMTO2Yuj7PbDTqqt qdfSSuiMrZdZ+9Du77fSQMGslKLcCj13QP3NHAlsT0b13UCJm6l1YRf5sZu5BJ2h8H0H HebDJJVx8QH8hbCPJP8knN2g/G3i2CgS7UkpvR5eRkx96fuVwFexjzDaZ7QPOuzilWbX LF7/VUAvnYmLZ51CVFEdw713mNwsiy3GpOWK2A8R0aQWgn9Ha93YWvWZjlO1qR+QD51f FB3RB79m/5+yWCiHAEvQwdXxMMAbNaUoo0U4/ZUMTKiWreVLPhUDLRPBMGPsdSpMzoL0 9+CQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y12si209724pgf.527.2018.11.26.04.52.48; Mon, 26 Nov 2018 04:53:23 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726614AbeKZXqQ (ORCPT + 99 others); Mon, 26 Nov 2018 18:46:16 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56524 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbeKZXqP (ORCPT ); Mon, 26 Nov 2018 18:46:15 -0500 Received: from pps.filterd (m0098394.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wAQChrfJ073832 for ; Mon, 26 Nov 2018 07:52:12 -0500 Received: from e06smtp05.uk.ibm.com (e06smtp05.uk.ibm.com [195.75.94.101]) by mx0a-001b2d01.pphosted.com with ESMTP id 2p0h338ak8-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 26 Nov 2018 07:52:12 -0500 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 26 Nov 2018 12:52:09 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Mon, 26 Nov 2018 12:52:04 -0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id wAQCq3uj56951028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 26 Nov 2018 12:52:03 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0569DA4065; Mon, 26 Nov 2018 12:52:03 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D525AA405F; Mon, 26 Nov 2018 12:52:00 +0000 (GMT) Received: from localhost.localdomain (unknown [9.80.88.39]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Mon, 26 Nov 2018 12:52:00 +0000 (GMT) Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files From: Mimi Zohar To: Casey Schaufler , Roberto Sassu , viro@zeniv.linux.org.uk Cc: linux-fsdevel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, initramfs@vger.kernel.org, linux-kernel@vger.kernel.org, silviu.vlasceanu@huawei.com, dmitry.kasatkin@huawei.com, takondra@cisco.com, kamensky@cisco.com, hpa@zytor.com, arnd@arndb.de, rob@landley.net, james.w.mcmechan@gmail.com, Greg KH , Andrew Morton Date: Mon, 26 Nov 2018 07:51:50 -0500 In-Reply-To: <6d6f3a60-7c80-4107-6d9b-be3d53cefefc@schaufler-ca.com> References: <20181122154942.18262-1-roberto.sassu@huawei.com> <3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com> <1543001453.4298.23.camel@linux.ibm.com> <6d6f3a60-7c80-4107-6d9b-be3d53cefefc@schaufler-ca.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18112612-0020-0000-0000-000002EDD706 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18112612-0021-0000-0000-0000213D242B Message-Id: <1543236710.3902.43.camel@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-26_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1811260118 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2018-11-23 at 18:07 -0800, Casey Schaufler wrote: > On 11/23/2018 11:30 AM, Mimi Zohar wrote: > > On Fri, 2018-11-23 at 11:03 -0800, Casey Schaufler wrote: > >> On 11/22/2018 7:49 AM, Roberto Sassu wrote: > >>> Although rootfs (tmpfs) supports xattrs, they are not set due to the > >>> limitation of the cpio format. A new format called 'newcx' was proposed to > >>> overcome this limitation. > >>> > >>> However, it looks like that adding a new format is not simple: 15 kernel > >>> patches; user space tools must support the new format; mistakes made in the > >>> past should be avoided; it is unclear whether the kernel should switch from > >>> cpio to tar. > >>> > >>> The aim of this patch is to provide the same functionality without > >>> introducing a new format. The value of xattrs is placed in regular files > >>> having the same file name as the files xattrs are added to, plus a > >>> separator and the xattr name (.xattr-). > >>> > >>> Example: > >>> > >>> '/bin/cat.xattr-security.ima' is the name of a file containing the value of > >>> the security.ima xattr to be added to /bin/cat. > >>> > >>> At kernel initialization time, the kernel iterates over the rootfs > >>> filesystem, and if it encounters files with the '.xattr-' separator, it > >>> reads the content and adds the xattr to the file without the suffix. > >> No. > >> > >> Really, no. > >> > >> It would be incredibly easy to use this mechanism to break > >> into systems. Assuming that the initramfs itself was signed, how? > >> > >>> This proposal requires that LSMs and IMA allow the read and setxattr > >>> operations. This should not be a concern since: files with xattr values > >>> are not parsed by the kernel; user space processes are not yet executed. > >>> > >>> It would be possible to include all xattrs in the same file, but this > >>> increases the risk of the kernel being compromised by parsing the content. > >> The kernel mustn't do this. > > Mustn't do what?  Store the xattr as separate detached files,  > > include all the xattrs in a single or per security/LSM xattr attribute > > file(s), or either? > > Any and all of the above. The proposed behavior is a kludge > around making the installation tools work correctly. Sure, it > may be easier to change the kernel than to change the utilities. > That's doesn't make it right. Modifying userspace tools, as Rob Landley pointed out in terms of toybox, isn't difficult.  The difficulty has been in reviewing and upstreaming the kernel CPIO changes. This patch was posted in order to address the lack of xattr support in the initramfs.  Before totally dismissing this or a similar solution, is there a safe method for including the xattrs? Would defining an LSM hook here help?  Each LSM would define its own method for storing and applying, or restoring, xattr labels. Mimi