Date:   Mon, 26 Nov 2018 08:17:58 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        viro@...iv.linux.org.uk
Cc:     linux-fsdevel@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-security-module@...r.kernel.org, initramfs@...r.kernel.org,
        linux-kernel@...r.kernel.org, silviu.vlasceanu@...wei.com,
        dmitry.kasatkin@...wei.com, takondra@...co.com, kamensky@...co.com,
        hpa@...or.com, arnd@...db.de, rob@...dley.net,
        james.w.mcmechan@...il.com, Greg KH <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/26/2018 4:51 AM, Mimi Zohar wrote:
> 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 (<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.
> Assuming that the initramfs itself was signed, how?

I don't share your faith in signatures.

>>>>> 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.

No sympathy from me there. And why wouldn't this scheme require
just as much review?

> 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?

The extension to CPIO sounds right to me.

> Would defining an LSM hook here help?  Each LSM would define its own
> method for storing and applying, or restoring, xattr labels.

I'm more concerned about how this could be used with file capabilities
than I am with access control attributes. I don't see how adding a hook
for this special case would help.

> Mimi

Powered by blists - more mailing lists