Message-ID: <d6479ebe656d4a75909b556d4cbcee22@huawei.com>
Date:   Wed, 15 Jun 2022 16:03:35 +0000
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Alexander Lobakin <alexandr.lobakin@...el.com>
CC:     "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "initramfs@...r.kernel.org" <initramfs@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bug-cpio@....org" <bug-cpio@....org>,
        "zohar@...ux.vnet.ibm.com" <zohar@...ux.vnet.ibm.com>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...wei.com>,
        "takondra@...co.com" <takondra@...co.com>,
        "kamensky@...co.com" <kamensky@...co.com>,
        "hpa@...or.com" <hpa@...or.com>, "arnd@...db.de" <arnd@...db.de>,
        "rob@...dley.net" <rob@...dley.net>,
        "james.w.mcmechan@...il.com" <james.w.mcmechan@...il.com>,
        "niveditas98@...il.com" <niveditas98@...il.com>
Subject: RE: [PATCH v4 0/3] initramfs: add support for xattrs in the initial
 ram disk

> From: Alexander Lobakin [mailto:alexandr.lobakin@...el.com]
> Sent: Wednesday, June 15, 2022 5:51 PM
> From: Roberto Sassu <roberto.sassu@...wei.com>
> Date: Thu, 23 May 2019 14:18:00 +0200
> 
> > 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
> 
> Hi,
> is this[0] relatable somehow?

Hi Alexander

seems a separate problem. For that, we opted for having a dedicated
kernel option:

https://github.com/openeuler-mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da

Thanks

Roberto

HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Li Peng, Yang Xi, Li He

> > security.ima xattr. Unfortunately, this use case cannot be implemented
> > currently, as the CPIO format does not support xattrs.
> >
> > This proposal consists in including file metadata as additional files named
> > METADATA!!!, for each file added to the ram disk. The CPIO parser in the
> > kernel recognizes these special files from the file name, and calls the
> > appropriate parser to add metadata to the previously extracted file. It has
> > been proposed to use bit 17:16 of the file mode as a way to recognize files
> > with metadata, but both the kernel and the cpio tool declare the file mode
> > as unsigned short.
> >
> > The difference from v2, v3 (https://lkml.org/lkml/2019/5/9/230,
> > https://lkml.org/lkml/2019/5/17/466) is that file metadata are stored in
> > separate files instead of a single file. Given that files with metadata
> > must immediately follow the files metadata will be added to, image
> > generators have to be modified in this version.
> >
> > The difference from v1 (https://lkml.org/lkml/2018/11/22/1182) is that
> > all files have the same name. The file metadata are added to is always the
> > previous one, and the image generator in user space will make sure that
> > files are in the correct sequence.
> >
> > 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. Files with metadata
> > will appear as regular files. It will be task of the parser in the kernel
> > to process them.
> >
> > This patch set extends the format of data defined in patch 9/15 of the last
> > proposal. It adds header version and type, so that new formats can be
> > defined and arbitrary metadata types can be processed.
> >
> > The changes introduced by this patch set don't cause any compatibility
> > issue: kernels without the metadata parser simply extract the special files
> > and don't process metadata; kernels with the metadata parser don't process
> > metadata if the special files are not included in the image.
> >
> > >>From the kernel space perspective, backporting this functionality to older
> > kernels should be very easy. It is sufficient to add two calls to the new
> > function do_process_metadata() in do_copy(), and to check the file name in
> > do_name(). From the user space perspective, unlike the previous version of
> > the patch set, it is required to modify the image generators in order to
> > include metadata as separate files.
> >
> > Changelog
> >
> > v3:
> > - include file metadata as separate files named METADATA!!!
> > - add the possibility to include in the ram disk arbitrary metadata types
> >
> > v2:
> > - replace ksys_lsetxattr() with kern_path() and vfs_setxattr()
> >   (suggested by Jann Horn)
> > - replace ksys_open()/ksys_read()/ksys_close() with
> >   filp_open()/kernel_read()/fput()
> >   (suggested by Jann Horn)
> > - use path variable instead of name_buf in do_readxattrs()
> > - set last byte of str to 0 in do_readxattrs()
> > - call do_readxattrs() in do_name() before replacing an existing
> >   .xattr-list
> > - pass pathname to do_setxattrs()
> >
> > v1:
> > - move xattr unmarshaling to CPIO parser
> >
> >
> > Mimi Zohar (1):
> >   initramfs: add file metadata
> >
> > Roberto Sassu (2):
> >   initramfs: read metadata from special file METADATA!!!
> >   gen_init_cpio: add support for file metadata
> >
> >  include/linux/initramfs.h |  21 ++++++
> >  init/initramfs.c          | 137 +++++++++++++++++++++++++++++++++++++-
> >  usr/Kconfig               |   8 +++
> >  usr/Makefile              |   4 +-
> >  usr/gen_init_cpio.c       | 137 ++++++++++++++++++++++++++++++++++++--
> >  usr/gen_initramfs_list.sh |  10 ++-
> >  6 files changed, 305 insertions(+), 12 deletions(-)
> >  create mode 100644 include/linux/initramfs.h
> >
> > --
> > 2.17.1
> 
> [0] https://lore.kernel.org/all/20210702233727.21301-1-alobakin@pm.me
> 
> Thanks,
> Olek

Powered by blists - more mailing lists