All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"initramfs@vger.kernel.org" <initramfs@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bug-cpio@gnu.org" <bug-cpio@gnu.org>,
	"zohar@linux.vnet.ibm.com" <zohar@linux.vnet.ibm.com>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@huawei.com>,
	"takondra@cisco.com" <takondra@cisco.com>,
	"kamensky@cisco.com" <kamensky@cisco.com>,
	"hpa@zytor.com" <hpa@zytor.com>, "arnd@arndb.de" <arnd@arndb.de>
Subject: RE: [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk
Date: Wed, 15 Jun 2022 16:03:35 +0000	[thread overview]
Message-ID: <d6479ebe656d4a75909b556d4cbcee22@huawei.com> (raw)
In-Reply-To: <20220615155034.1271240-1-alexandr.lobakin@intel.com>

> From: Alexander Lobakin [mailto:alexandr.lobakin@intel.com]
> Sent: Wednesday, June 15, 2022 5:51 PM
> From: Roberto Sassu <roberto.sassu@huawei.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

WARNING: multiple messages have this Message-ID (diff)
From: Roberto Sassu <roberto.sassu@huawei.com>
To: Alexander Lobakin <alexandr.lobakin@intel.com>
Cc: "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"linux-integrity@vger.kernel.org"
	<linux-integrity@vger.kernel.org>,
	"initramfs@vger.kernel.org" <initramfs@vger.kernel.org>,
	"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"bug-cpio@gnu.org" <bug-cpio@gnu.org>,
	"zohar@linux.vnet.ibm.com" <zohar@linux.vnet.ibm.com>,
	Silviu Vlasceanu <Silviu.Vlasceanu@huawei.com>,
	Dmitry Kasatkin <dmitry.kasatkin@huawei.com>,
	"takondra@cisco.com" <takondra@cisco.com>,
	"kamensky@cisco.com" <kamensky@cisco.com>,
	"hpa@zytor.com" <hpa@zytor.com>, "arnd@arndb.de" <arnd@arndb.de>,
	"rob@landley.net" <rob@landley.net>,
	"james.w.mcmechan@gmail.com" <james.w.mcmechan@gmail.com>,
	"niveditas98@gmail.com" <niveditas98@gmail.com>
Subject: RE: [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk
Date: Wed, 15 Jun 2022 16:03:35 +0000	[thread overview]
Message-ID: <d6479ebe656d4a75909b556d4cbcee22@huawei.com> (raw)
In-Reply-To: <20220615155034.1271240-1-alexandr.lobakin@intel.com>

> From: Alexander Lobakin [mailto:alexandr.lobakin@intel.com]
> Sent: Wednesday, June 15, 2022 5:51 PM
> From: Roberto Sassu <roberto.sassu@huawei.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

  reply	other threads:[~2022-06-15 16:03 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-23 12:18 [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk Roberto Sassu
2019-05-23 12:18 ` Roberto Sassu
2019-05-23 12:18 ` Roberto Sassu
2019-05-23 12:18 ` [PATCH v4 1/3] initramfs: add file metadata Roberto Sassu
2019-05-23 12:18   ` Roberto Sassu
     [not found]   ` <20190523121803.21638-2-roberto.sassu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2022-06-15 17:54     ` Eugeniu Rosca
2022-06-15 17:54       ` Eugeniu Rosca
2019-05-23 12:18 ` [PATCH v4 2/3] initramfs: read metadata from special file METADATA!!! Roberto Sassu
2019-05-23 12:18   ` Roberto Sassu
2019-07-01 12:54   ` Mimi Zohar
2019-07-01 12:54     ` Mimi Zohar
2019-05-23 12:18 ` [PATCH v4 3/3] gen_init_cpio: add support for file metadata Roberto Sassu
2019-05-23 12:18   ` Roberto Sassu
2019-06-30 15:27   ` Mimi Zohar
2022-06-16 14:47   ` Eugeniu Rosca
2022-06-16 14:47     ` Eugeniu Rosca
     [not found]   ` <20190523121803.21638-4-roberto.sassu-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2022-06-16 15:16     ` Eugeniu Rosca
2022-06-16 15:16       ` Eugeniu Rosca
2022-06-30 15:06       ` Roberto Sassu
2022-06-30 15:06         ` Roberto Sassu
2022-06-30 20:38         ` Eugeniu Rosca
2022-06-30 20:38           ` Eugeniu Rosca
2019-06-03  9:31 ` [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk Roberto Sassu
2019-06-03  9:31   ` Roberto Sassu
2019-06-03 18:32   ` Rob Landley
2019-06-26  8:15     ` Roberto Sassu
2019-06-26  8:15       ` Roberto Sassu
2019-06-30 15:39       ` Mimi Zohar
2019-07-01 13:42         ` Roberto Sassu
2019-07-01 13:42           ` Roberto Sassu
2019-07-01 14:31           ` Mimi Zohar
2019-07-15 16:54             ` Roberto Sassu
2019-07-15 16:54               ` Roberto Sassu
2019-07-24 15:34               ` Roberto Sassu
2019-07-24 15:34                 ` Roberto Sassu
2022-06-09 10:26                 ` Eugeniu Rosca
2022-06-09 10:26                   ` Eugeniu Rosca
2022-06-09 11:05                   ` Roberto Sassu
2022-06-09 11:05                     ` Roberto Sassu
2022-06-10 15:33                     ` Eugeniu Rosca
2022-06-10 15:33                       ` Eugeniu Rosca
2022-06-10 15:38                       ` Roberto Sassu
2022-06-10 15:38                         ` Roberto Sassu
2022-06-15  9:27                         ` Eugeniu Rosca
2022-06-15  9:27                           ` Eugeniu Rosca
2022-07-18 16:36                           ` Jim Baxter
2022-07-18 16:36                             ` Jim Baxter
     [not found]                             ` <032ade35-6eb8-d698-ac44-aa45d46752dd-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2022-07-18 16:49                               ` Roberto Sassu
2022-07-18 16:49                                 ` Roberto Sassu
2022-07-18 18:08                                 ` Jim Baxter
2022-07-18 18:08                                   ` Jim Baxter
2022-07-19  6:55                                   ` Roberto Sassu
2022-07-19  6:55                                     ` Roberto Sassu
     [not found]                                     ` <8e6a723874644449be99fcebb0905058-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2022-07-19 11:50                                       ` Rob Landley
2022-07-19 11:50                                         ` Rob Landley
     [not found]                                         ` <dc86769f-0ac6-d9f3-c003-54d3793ccfec-VoJi6FS/r0vR7s880joybQ@public.gmane.org>
2022-07-19 12:26                                           ` Roberto Sassu
2022-07-19 12:26                                             ` Roberto Sassu
2022-07-19 14:14                                             ` Rob Landley
2022-07-19 14:14                                               ` Rob Landley
2022-07-20 11:52                                               ` Roberto Sassu
2022-07-20 11:52                                                 ` Roberto Sassu
2022-07-29 10:37                                     ` Jim Baxter
2022-07-29 10:37                                       ` Jim Baxter
2022-07-30  9:39                                       ` Rob Landley
2022-07-30  9:39                                         ` Rob Landley
     [not found]                                   ` <737ddf72-05f4-a47e-c901-fec5b1dfa7a6-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
2022-07-19 11:33                                     ` Rob Landley
2022-07-19 11:33                                       ` Rob Landley
2022-07-19 11:00                                 ` Rob Landley
2022-07-19 11:00                                   ` Rob Landley
2019-07-01 13:22 ` Mimi Zohar
2022-06-15 15:50 ` Alexander Lobakin
2022-06-15 16:03   ` Roberto Sassu [this message]
2022-06-15 16:03     ` Roberto Sassu
2022-06-16 13:24 ` Eugeniu Rosca
2022-06-16 13:24   ` Eugeniu Rosca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d6479ebe656d4a75909b556d4cbcee22@huawei.com \
    --to=roberto.sassu@huawei.com \
    --cc=Silviu.Vlasceanu@huawei.com \
    --cc=alexandr.lobakin@intel.com \
    --cc=arnd@arndb.de \
    --cc=bug-cpio@gnu.org \
    --cc=dmitry.kasatkin@huawei.com \
    --cc=hpa@zytor.com \
    --cc=initramfs@vger.kernel.org \
    --cc=kamensky@cisco.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=takondra@cisco.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=zohar@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.