From: Mimi Zohar <zohar@linux.ibm.com>
To: Florent Revest <revest@chromium.org>,
Casey Schaufler <casey@schaufler-ca.com>,
linux-integrity@vger.kernel.org
Cc: jmorris@namei.org, serge@hallyn.com, revest@google.com,
allison@lohutok.net, armijn@tjaldur.nl, bauerman@linux.ibm.com,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, kpsingh@chromium.org
Subject: Re: [PATCH] integrity: Expose data structures required for include/linux/integrity.h
Date: Wed, 18 Dec 2019 08:34:47 -0500 [thread overview]
Message-ID: <1576676087.4579.396.camel@linux.ibm.com> (raw)
In-Reply-To: <2ae5127d76cbf78140fb2d6108c9ec70c7d8ae5d.camel@chromium.org>
On Wed, 2019-12-18 at 12:03 +0100, Florent Revest wrote:
> On Tue, 2019-12-17 at 18:08 -0500, Mimi Zohar wrote:
> > On Tue, 2019-12-17 at 08:25 -0800, Casey Schaufler wrote:
> > > On 12/17/2019 5:47 AM, Florent Revest wrote:
> > > > From: Florent Revest <revest@google.com>
> > > >
> > > > include/linux/integrity.h exposes the prototype of
> > > > integrity_inode_get().
> > > > However, it relies on struct integrity_iint_cache which is
> > > > currently
> > > > defined in an internal header, security/integrity/integrity.h.
> > > >
> > > > To allow the rest of the kernel to use integrity_inode_get,
> > >
> > > Why do you want to do this?
> >
> > ditto
>
> My team works on KRSI (eBPF MAC policies presented at LSS by KP Singh).
> https://lkml.org/lkml/2019/9/10/393 We identified file hashes gathered
> from the integrity subsystem as an interesting field that we could
> potentially someday expose to eBPF programs through helpers.
>
> One of the reason behind writing KRSI is to replace a custom kernel
> auditing module that currently needs to redefine those structures to
> access them. I imagine other kernel modules could benefit from a file
> hash API too.
>
> This is the least intrusive patch I could come up with that allows us
> to lookup a hash from an inode. I was surprised to find that
> integrity_inode_get was exposed but not the structures it returns.
>
> If the community is interested in a different file hash API, I'd be
> happy to iterate on this patch based on your feedback.
There's a major difference between returning just the file hash and
making the integrity_iint_cache structure public. Peter Moody's
original code queried the cache[1]. Why do you need access to the
structure itself?
FYI, if/when we get to IMA namespacing, the cache structure will
change.
Mimi
[1] ima: add the ability to query ima for the hash of a given file.
>
> > > > this patch
> > > > moves the definition of the necessary structures from a private
> > > > header
> > > > to a global kernel header.
>
next prev parent reply other threads:[~2019-12-18 13:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-17 13:47 [PATCH] integrity: Expose data structures required for include/linux/integrity.h Florent Revest
2019-12-17 16:25 ` Casey Schaufler
2019-12-17 23:08 ` Mimi Zohar
2019-12-18 11:03 ` Florent Revest
2019-12-18 13:34 ` Mimi Zohar [this message]
2019-12-18 14:28 ` Mimi Zohar
2019-12-18 16:56 ` Florent Revest
2019-12-18 18:43 ` 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=1576676087.4579.396.camel@linux.ibm.com \
--to=zohar@linux.ibm.com \
--cc=allison@lohutok.net \
--cc=armijn@tjaldur.nl \
--cc=bauerman@linux.ibm.com \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=kpsingh@chromium.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=revest@chromium.org \
--cc=revest@google.com \
--cc=serge@hallyn.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.