From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mimi Zohar Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files Date: Fri, 23 Nov 2018 14:30:53 -0500 Message-ID: <1543001453.4298.23.camel@linux.ibm.com> References: <20181122154942.18262-1-roberto.sassu@huawei.com> <3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="utf-8" 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 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. >   > > > 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? Mimi