linux-kernel.vger.kernel.org archive mirror
 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>,
	"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: 40+ 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 ` [PATCH v4 1/3] initramfs: add file metadata Roberto Sassu
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-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-06-30 15:27   ` Mimi Zohar
2022-06-16 14:47   ` Eugeniu Rosca
2022-06-16 15:16   ` Eugeniu Rosca
2022-06-30 15:06     ` Roberto Sassu
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 18:32   ` Rob Landley
2019-06-26  8:15     ` Roberto Sassu
2019-06-30 15:39       ` Mimi Zohar
2019-07-01 13:42         ` Roberto Sassu
2019-07-01 14:31           ` Mimi Zohar
2019-07-15 16:54             ` Roberto Sassu
2019-07-24 15:34               ` Roberto Sassu
2022-06-09 10:26                 ` Eugeniu Rosca
2022-06-09 11:05                   ` Roberto Sassu
2022-06-10 15:33                     ` Eugeniu Rosca
2022-06-10 15:38                       ` Roberto Sassu
2022-06-15  9:27                         ` Eugeniu Rosca
2022-07-18 16:36                           ` Jim Baxter
2022-07-18 16:49                             ` Roberto Sassu
2022-07-18 18:08                               ` Jim Baxter
2022-07-19  6:55                                 ` Roberto Sassu
2022-07-19 11:50                                   ` Rob Landley
2022-07-19 12:26                                     ` Roberto Sassu
2022-07-19 14:14                                       ` Rob Landley
2022-07-20 11:52                                         ` Roberto Sassu
2022-07-29 10:37                                   ` Jim Baxter
2022-07-30  9:39                                     ` Rob Landley
2022-07-19 11:33                                 ` 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-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=james.w.mcmechan@gmail.com \
    --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=niveditas98@gmail.com \
    --cc=rob@landley.net \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).