[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXy7gqmmy37=nrMAisGadZ+qbjZjXtWFF8Crq86xNpsfA@mail.gmail.com>
Date: Sat, 11 May 2019 15:44:12 -0700
From: Andy Lutomirski <luto@...nel.org>
To: Roberto Sassu <roberto.sassu@...wei.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
LSM List <linux-security-module@...r.kernel.org>,
linux-integrity <linux-integrity@...r.kernel.org>,
initramfs@...r.kernel.org, Linux API <linux-api@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
silviu.vlasceanu@...wei.com, dmitry.kasatkin@...wei.com,
takondra@...co.com, kamensky@...co.com,
"H. Peter Anvin" <hpa@...or.com>, Arnd Bergmann <arnd@...db.de>,
Rob Landley <rob@...dley.net>, james.w.mcmechan@...il.com
Subject: Re: [PATCH v2 0/3] initramfs: add support for xattrs in the initial
ram disk
On Thu, May 9, 2019 at 4:27 AM Roberto Sassu <roberto.sassu@...wei.com> wrote:
>
> This patch set aims at solving the following use case: appraise files from
> the initial ram disk. To do that, IMA checks the signature/hash from the
> security.ima xattr. Unfortunately, this use case cannot be implemented
> currently, as the CPIO format does not support xattrs.
>
> This proposal consists in marshaling pathnames and xattrs in a file called
> .xattr-list. They are unmarshaled by the CPIO parser after all files have
> been extracted.
>
> The difference from v1 (https://lkml.org/lkml/2018/11/22/1182) is that all
> xattrs are stored in a single file and not per file (solves the file name
> limitation issue, as it is not necessary to add a suffix to files
> containing xattrs).
>
> The difference with another proposal
> (https://lore.kernel.org/patchwork/cover/888071/) is that xattrs can be
> included in an image without changing the image format, as opposed to
> defining a new one. As seen from the discussion, if a new format has to be
> defined, it should fix the issues of the existing format, which requires
> more time.
I read some of those emails. ISTM that adding TAR support should be
seriously considered. Sure, it's baroque, but it's very, very well
supported, and it does exactly what we need.
--Andy
Powered by blists - more mailing lists