Message-ID: <f2886ac7-aff9-94bc-5f65-b3b2e946a6ff@schaufler-ca.com>
Date:   Mon, 26 Nov 2018 08:34:54 -0800
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        Rob Landley <rob@...dley.net>, 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, zohar@...ux.ibm.com,
        silviu.vlasceanu@...wei.com, dmitry.kasatkin@...wei.com,
        takondra@...co.com, kamensky@...co.com, hpa@...or.com,
        arnd@...db.de, james.w.mcmechan@...il.com
Subject: Re: [RFC][PATCH] fs: set xattrs in initramfs from regular files

On 11/26/2018 4:56 AM, Roberto Sassu wrote:
> On 11/23/2018 9:21 PM, Rob Landley wrote:
>> On 11/22/18 9: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.
>>
>> I got email about that format the day before you posted this, by the way.
>>
>>> 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 kernel _can't_ switch from cpio to tar without breaking backwards
>> compatability, it could only add tar as a second format it supported (remember
>> cpio images can be sideloaded so a new rootfs can be used with an existing
>> initramfs, plus existing build systems generate them and would still need to if
>> they wanted to keep supporting older kernels), and then once you've got two
>> formats somebody will propose zip support, and let's just not go there please.
>>
>> The changes to the userspace tools are trivial (I say that as the maintainer of
>> toybox, which has a cpio). The argument was about things like 64 bit timestamps
>> (y2038 problem), nanosecond support, sparse files, etc. And I think the argument
>> had largely died down?
>>
>> Keep in mind the squashfs guy spent 5 years trying to get his filesystem merged
>> (https://lwn.net/Articles/563578/), I spent several years trying to get my perl
>> removal patch merged (and only work up the enthusiasm to resubmit
>> http://lists.busybox.net/pipermail/buildroot/2015-March/123385.html
>> https://patchwork.kernel.org/patch/9193529/ https://lkml.org/lkml/2017/9/13/651
>> about once a year because dealing with linux-kernel is just no fun for hobbyists
>> anymore).
>>
>>> 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>).
>>
>> I think you're solving the wrong problem, but that's just my opinion.
>
> Instead of iterating over rootfs, would it be better to detect files
> with extended attributes (from the file name) when the cpio image is
> parsed by the kernel, and call sys_lsetxattr() in do_copy()? This part
> can be turned on by introducing a new type in the existing format (if
> possible).

A very similar approach was used in at least one MLS Unix
system back in the day. It used tar, but would have worked
just as well with CPIO. Any file with a specific name
was assumed to contain the security attributes for the
preceding file, and tar invoked a helper program to set
them. No change to the tar format was required, and if
you read an archive with a generic tar you just got multiple
entries for the special name. No format or special types
required.

>
> The impact of this alternative is very low, and LSMs/IMA would be able,
> with minimum effort, to enforce policies on files in the initial ram
> disk.

True. And it worked. But it was still a kludge.

Powered by blists - more mailing lists