On Fri, 2019-05-10 at 15:46 -0500, Rob Landley wrote: > On 5/10/19 6:49 AM, Mimi Zohar wrote: > > On Fri, 2019-05-10 at 08:56 +0200, Roberto Sassu wrote: > >> On 5/9/2019 8:34 PM, Rob Landley wrote: > >>> On 5/9/19 6:24 AM, Roberto Sassu wrote: > > > >>>> 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. > >>> > >>> So you've explicitly chosen _not_ to address Y2038 while you're there. > >> > >> Can you be more specific? > > > > Right, this patch set avoids incrementing the CPIO magic number and > > the resulting changes required (eg. increasing the timestamp field > > size), by including a file with the security xattrs in the CPIO. In > > either case, including the security xattrs in the initramfs header or > > as a separate file, the initramfs, itself, needs to be signed. > > The /init binary in the initramfs runs as root and launches all other processes > on the system. Presumably it can write any xattrs it wants to, and doesn't need > any extra permissions granted to it to do so. But as soon as you start putting > xattrs on _other_ files within the initramfs that are _not_ necessarily running > as PID 1, _that's_ when the need to sign the initramfs comes in? > > Presumably the signing occurs on the gzipped file. How does that affect the cpio > parsing _after_ it's decompressed? Why would that be part of _this_ patch? The signing and verification of the initramfs is a separate issue, not part of this patch set. The only reason for mentioning it here was to say that both methods of including the security xattrs require the initramfs be signed. Just as the kernel image needs to be signed and verified, the initramfs should be too. Mimi
