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;
Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files
From:   Mimi Zohar <zohar@linux.ibm.com>
To:     Casey Schaufler <casey@schaufler-ca.com>,
        Roberto Sassu <roberto.sassu@huawei.com>,
        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
Date:   Fri, 23 Nov 2018 14:30:53 -0500
In-Reply-To: <3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com>
References: <20181122154942.18262-1-roberto.sassu@huawei.com>
         <3d1bfbd7-7d45-4cf1-32d6-7f6985b42393@schaufler-ca.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <1543001453.4298.23.camel@linux.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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 (<filename>.xattr-<xattr name>).
> >
> > 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