[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dca50ee1-62d8-2256-6fdb-9a786e6cea5a@landley.net>
Date: Sun, 12 May 2019 12:05:48 -0500
From: Rob Landley <rob@...dley.net>
To: Mimi Zohar <zohar@...ux.ibm.com>,
Dominik Brodowski <linux@...inikbrodowski.net>,
Roberto Sassu <roberto.sassu@...wei.com>
Cc: viro@...iv.linux.org.uk, linux-security-module@...r.kernel.org,
linux-integrity@...r.kernel.org, initramfs@...r.kernel.org,
linux-api@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-kernel@...r.kernel.org, zohar@...ux.vnet.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: [PATCH v2 0/3] initramfs: add support for xattrs in the initial
ram disk
On 5/12/19 7:52 AM, Mimi Zohar wrote:
> On Sun, 2019-05-12 at 11:17 +0200, Dominik Brodowski wrote:
>> On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
>>> 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.
>>
>> Couldn't this parsing of the .xattr-list file and the setting of the xattrs
>> be done equivalently by the initramfs' /init? Why is kernel involvement
>> actually required here?
>
> It's too late. The /init itself should be signed and verified.
If the initramfs cpio.gz image was signed and verified by the extractor, how is
the init in it _not_ verified?
Rob
Powered by blists - more mailing lists