public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	linux-xfs <linux-xfs@vger.kernel.org>
Subject: Re: [PATCH] xfs: include the XFS magic number in magic.h
Date: Wed, 13 Dec 2017 11:13:42 +1100	[thread overview]
Message-ID: <20171213001342.GY5858@dastard> (raw)
In-Reply-To: <1513122931.3476.97.camel@linux.vnet.ibm.com>

On Tue, Dec 12, 2017 at 06:55:31PM -0500, Mimi Zohar wrote:
> On Wed, 2017-12-13 at 10:30 +1100, Dave Chinner wrote:
> > On Tue, Dec 12, 2017 at 10:04:56AM -0500, Mimi Zohar wrote:
> > > On Tue, 2017-12-12 at 06:36 -0800, Christoph Hellwig wrote:
> > > > On Tue, Dec 12, 2017 at 09:34:56AM -0500, Mimi Zohar wrote:
> > > > > On Tue, 2017-12-12 at 06:26 -0800, Christoph Hellwig wrote:
> > > > > > On Tue, Dec 12, 2017 at 09:21:09AM -0500, Mimi Zohar wrote:
> > > > > > > Move the XFS_SB_MAGIC definition to magic.h.
> > > > > > 
> > > > > > NACK.  We want to keep the XFS code self-contained and no other part
> > > > > > of the kernel has any business knowing it anyway.
> > > > > 
> > > > > IMA policy rules can be defined in terms of magic numbers, but they
> > > > > need to be defined in magic.h.  Please reconsider...
> > > > 
> > > > That is completely bogus, and it should not be supported in any way.
> > > > File systems magic numbers are internal implementation details.
> > > 
> > > Perhaps policies in general shouldn't differentiate between file
> > > systems, but it definitely simplifies testing.
> > 
> > How does specifying a filesystem type in a generic layer's policy
> > implementation help testing?
> 
> Based on file system, I could differentiate which files need to be
> signed.  For example, the root file system might require files
> signatures only on executables, while for other file systems all files
> could require signatures.

What's the filesystem magic number got to do with where the
filesystem is mounted or what it contains?

> > > For example, currently IMA-appraisal only supports storing file
> > > signatures as xattrs, but support for appended signatures is being
> > > added.  Per file system rules could require different types of file
> > > signatures.
> > 
> > What's an "appended signature", and why is the filesystem
> > independent xattr interface insufficient for storing this
> > information?
> 
> Unfortunately, not all filesystems support xattrs (eg.
> cpio/initramfs).

So add support to them....

>  In some cases, like kexec kernel image and
> initramfs, having an attached signatures simplifies network boot.

... or support fetching detached signatures for these very specific
use cases.

> scripts/sign-file is used to append a file signature to kernel
> modules.  This same script could be used for signing other files, like
> the kexec kernel image and initramfs.

This doesn't require knowing about what type of filesystem the file
is read from. It's just data appended to the file, and you can
already read filesystem without knowing what the underlying
filesystem implementation is....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2017-12-13  0:13 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 14:21 [PATCH] xfs: include the XFS magic number in magic.h Mimi Zohar
2017-12-12 14:26 ` Christoph Hellwig
2017-12-12 14:34   ` Mimi Zohar
2017-12-12 14:36     ` Christoph Hellwig
2017-12-12 15:04       ` Mimi Zohar
2017-12-12 23:30         ` Dave Chinner
2017-12-12 23:55           ` Mimi Zohar
2017-12-13  0:13             ` Dave Chinner [this message]
2017-12-13  1:21               ` Mimi Zohar
2017-12-13  2:59                 ` Dave Chinner
2017-12-13  8:43                   ` Christoph Hellwig
2017-12-13 14:04                   ` Mimi Zohar
2017-12-12 21:13 ` Dave Chinner
2017-12-12 23:35   ` Mimi Zohar

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=20171213001342.GY5858@dastard \
    --to=david@fromorbit.com \
    --cc=hch@infradead.org \
    --cc=linux-xfs@vger.kernel.org \
    --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