From: Roberto Sassu <roberto.sassu@huaweicloud.com>
To: Paul Moore <paul@paul-moore.com>
Cc: corbet@lwn.net, jmorris@namei.org, serge@hallyn.com,
akpm@linux-foundation.org, shuah@kernel.org,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
mic@digikod.net, linux-security-module@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, bpf@vger.kernel.org,
zohar@linux.ibm.com, dmitry.kasatkin@gmail.com,
linux-integrity@vger.kernel.org, wufan@linux.microsoft.com,
pbrobinson@gmail.com, zbyszek@in.waw.pl, hch@lst.de,
mjg59@srcf.ucam.org, pmatilai@redhat.com, jannh@google.com,
dhowells@redhat.com, jikos@kernel.org, mkoutny@suse.com,
ppavlu@suse.com, petr.vorel@gmail.com, mzerqung@0pointer.de,
kgold@linux.ibm.com, Roberto Sassu <roberto.sassu@huawei.com>
Subject: Re: [PATCH v4 00/14] security: digest_cache LSM
Date: Thu, 20 Jun 2024 18:30:31 +0200 [thread overview]
Message-ID: <c732b1eb15141f909e99247192539b7f76e9952c.camel@huaweicloud.com> (raw)
In-Reply-To: <CAHC9VhSQOiC9t0qk10Lg3o6eAFdrR2QFLvCn1h2EP+P+AgdSbw@mail.gmail.com>
On Thu, 2024-06-20 at 12:08 -0400, Paul Moore wrote:
> On Thu, Jun 20, 2024 at 11:14 AM Roberto Sassu
> <roberto.sassu@huaweicloud.com> wrote:
> > On Thu, 2024-06-20 at 10:48 -0400, Paul Moore wrote:
> > > On Thu, Jun 20, 2024 at 5:12 AM Roberto Sassu
> > > <roberto.sassu@huaweicloud.com> wrote:
> > > > On Wed, 2024-06-19 at 14:43 -0400, Paul Moore wrote:
> > > > > On Wed, Jun 19, 2024 at 12:38 PM Roberto Sassu
> > > > > <roberto.sassu@huaweicloud.com> wrote:
> > > > > >
> > > > > > Making it a kernel subsystem would likely mean replicating what the LSM
> > > > > > infrastructure is doing, inode (security) blob and being notified about
> > > > > > file/directory changes.
> > > > >
> > > > > Just because the LSM framework can be used for something, perhaps it
> > > > > even makes the implementation easier, it doesn't mean the framework
> > > > > should be used for everything.
> > > >
> > > > It is supporting 3 LSMs: IMA, IPE and BPF LSM.
> > > >
> > > > That makes it a clear target for the security subsystem, and as you
> > > > suggested to start for IMA, if other kernel subsystems require them, we
> > > > can make it as an independent subsystem.
> > >
> > > Have you discussed the file digest cache functionality with either the
> > > IPE or BPF LSM maintainers? While digest_cache may support these
> >
> > Well, yes. I was in a discussion since long time ago with Deven and
> > Fan. The digest_cache LSM is listed in the Use Case section of the IPE
> > cover letter:
> >
> > https://lore.kernel.org/linux-integrity/1716583609-21790-1-git-send-email-wufan@linux.microsoft.com/
>
> I would hope to see more than one sentence casually mentioning that
> there might be some integration in the future.
Sure, I can work more with Fan to do a proper integration.
> > I also developed an IPE module back in the DIGLIM days:
> >
> > https://lore.kernel.org/linux-integrity/a16a628b9e21433198c490500a987121@huawei.com/
>
> That looks like more of an fs-verity integration to me. Yes, of
> course there would be IPE changes to accept a signature/digest from a
> digest cache, but that should be minor.
True, but IPE will also benefit from not needing to specify every
digest in the policy.
Also, the design choice of attaching the digest cache to the inode
helps LSMs like IPE that don't have a per inode cache on their own.
Sure, IPE would have to do a digest lookup every time, but at least on
an already populated hash table.
> > As for eBPF, I just need to make the digest_cache LSM API callable by
> > eBPF programs, very likely not requiring any change on the eBPF
> > infrastructure itself.
>
> That's great, but it would be good to hear from KP and any other BPF
> LSM devs that this would be desirable.
Yes, I would also like to know their opinion. They already support
getting a file digest from IMA. Adding support for the digest_cache LSM
is a nice complement, to make security decisions based on an
authenticated source of reference digests (signature verification was
not shown in the example).
> I still believe that this is something that should live as a service
> outside of the LSM.
It will not cost me too much to plug to IMA rather than the LSM
infrastructure, but I would rather prefer the second.
I'm not aware of equivalent facilities in the kernel that would make
the digest_cache LSM work in the same way, so making it as an
independent kernel subsystem seems a too big jump for me.
Roberto
next prev parent reply other threads:[~2024-06-20 16:31 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-15 14:24 [PATCH v4 00/14] security: digest_cache LSM Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 01/14] lib: Add TLV parser Roberto Sassu
2024-04-15 19:19 ` Jarkko Sakkinen
2024-04-15 21:07 ` Randy Dunlap
2024-04-16 14:23 ` Jarkko Sakkinen
2024-04-15 14:24 ` [PATCH v4 02/14] security: Introduce the digest_cache LSM Roberto Sassu
2024-04-15 19:31 ` Jarkko Sakkinen
2024-04-16 7:09 ` Roberto Sassu
2024-04-16 14:33 ` Jarkko Sakkinen
2024-04-17 17:00 ` Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 03/14] digest_cache: Add securityfs interface Roberto Sassu
2024-04-15 19:32 ` Jarkko Sakkinen
2024-04-16 10:15 ` Roberto Sassu
2024-04-16 14:38 ` Jarkko Sakkinen
2024-04-15 14:24 ` [PATCH v4 04/14] digest_cache: Add hash tables and operations Roberto Sassu
2024-04-15 19:36 ` Jarkko Sakkinen
2024-04-16 10:28 ` Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 05/14] digest_cache: Populate the digest cache from a digest list Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 06/14] digest_cache: Parse tlv digest lists Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 07/14] digest_cache: Parse rpm " Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 08/14] digest_cache: Add management of verification data Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 09/14] digest_cache: Add support for directories Roberto Sassu
2024-04-15 19:39 ` Jarkko Sakkinen
2024-04-16 10:30 ` Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 10/14] digest cache: Prefetch digest lists if requested Roberto Sassu
2024-04-15 19:42 ` Jarkko Sakkinen
2024-04-16 10:34 ` Roberto Sassu
2024-04-16 14:47 ` Jarkko Sakkinen
2024-04-15 14:24 ` [PATCH v4 11/14] digest_cache: Reset digest cache on file/directory change Roberto Sassu
2024-04-15 19:44 ` Jarkko Sakkinen
2024-04-16 10:37 ` Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 12/14] digest_cache: Notify digest cache events Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 13/14] selftests/digest_cache: Add selftests for digest_cache LSM Roberto Sassu
2024-04-15 19:47 ` Jarkko Sakkinen
2024-04-16 10:39 ` Roberto Sassu
2024-04-15 14:24 ` [PATCH v4 14/14] docs: Add documentation of the " Roberto Sassu
2024-04-15 19:18 ` [PATCH v4 00/14] security: " Jarkko Sakkinen
2024-04-16 6:56 ` Roberto Sassu
2024-04-16 4:49 ` Bagas Sanjaya
[not found] ` <66201cd2.df0a0220.a8ad5.6fbaSMTPIN_ADDED_BROKEN@mx.google.com>
2024-04-19 11:18 ` Bagas Sanjaya
2024-04-19 20:05 ` Jarkko Sakkinen
2024-04-19 23:29 ` Roberto Sassu
2024-06-18 23:20 ` Paul Moore
2024-06-19 7:59 ` Roberto Sassu
2024-06-19 15:49 ` Paul Moore
2024-06-19 15:55 ` Roberto Sassu
2024-06-19 16:34 ` Paul Moore
2024-06-19 16:37 ` Roberto Sassu
2024-06-19 18:43 ` Paul Moore
2024-06-20 9:12 ` Roberto Sassu
2024-06-20 9:16 ` Roberto Sassu
2024-06-20 14:48 ` Paul Moore
2024-06-20 15:14 ` Roberto Sassu
2024-06-20 16:08 ` Paul Moore
2024-06-20 16:30 ` Roberto Sassu [this message]
2024-06-20 16:51 ` Paul Moore
2024-06-20 17:05 ` Roberto Sassu
2024-06-20 17:13 ` Paul Moore
2024-06-21 7:10 ` Roberto Sassu
2024-06-20 16:32 ` Dr. Greg
2024-06-20 16:54 ` Roberto Sassu
-- strict thread matches above, loose matches on Subject: below --
2024-04-15 14:16 Roberto Sassu
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=c732b1eb15141f909e99247192539b7f76e9952c.camel@huaweicloud.com \
--to=roberto.sassu@huaweicloud.com \
--cc=akpm@linux-foundation.org \
--cc=alexandre.torgue@foss.st.com \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=hch@lst.de \
--cc=jannh@google.com \
--cc=jikos@kernel.org \
--cc=jmorris@namei.org \
--cc=kgold@linux.ibm.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mcoquelin.stm32@gmail.com \
--cc=mic@digikod.net \
--cc=mjg59@srcf.ucam.org \
--cc=mkoutny@suse.com \
--cc=mzerqung@0pointer.de \
--cc=paul@paul-moore.com \
--cc=pbrobinson@gmail.com \
--cc=petr.vorel@gmail.com \
--cc=pmatilai@redhat.com \
--cc=ppavlu@suse.com \
--cc=roberto.sassu@huawei.com \
--cc=serge@hallyn.com \
--cc=shuah@kernel.org \
--cc=wufan@linux.microsoft.com \
--cc=zbyszek@in.waw.pl \
--cc=zohar@linux.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 read-only IMAP folder(s) and NNTP newsgroup(s).