On Wed, Jun 19, 2024 at 06:37:49PM +0200, Roberto Sassu wrote:
Good morning Roberto, I hope your week is going well, greetings to
everyone copied else as well.
> On Wed, 2024-06-19 at 12:34 -0400, Paul Moore wrote:
> > On Wed, Jun 19, 2024 at 11:55???AM Roberto Sassu
> > <roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> > > On Wed, 2024-06-19 at 11:49 -0400, Paul Moore wrote:
> > > > On Wed, Jun 19, 2024 at 3:59???AM Roberto Sassu
> > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> > > > > On Tue, 2024-06-18 at 19:20 -0400, Paul Moore wrote:
> > > > > > On Mon, Apr 15, 2024 at 10:25???AM Roberto Sassu
> > > > > > <roberto.sassu@xxxxxxxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > From: Roberto Sassu <roberto.sassu@xxxxxxxxxx>
> > > > > > >
> > > > > > > Integrity detection and protection has long been a desirable feature, to
> > > > > > > reach a large user base and mitigate the risk of flaws in the software
> > > > > > > and attacks.
> > > > > > >
> > > > > > > However, while solutions exist, they struggle to reach the large user
> > > > > > > base, due to requiring higher than desired constraints on performance,
> > > > > > > flexibility and configurability, that only security conscious people are
> > > > > > > willing to accept.
> > > > > > >
> > > > > > > This is where the new digest_cache LSM comes into play, it offers
> > > > > > > additional support for new and existing integrity solutions, to make
> > > > > > > them faster and easier to deploy.
> > > > > > >
> > > > > > > The full documentation with the motivation and the solution details can be
> > > > > > > found in patch 14.
> > > > > > >
> > > > > > > The IMA integration patch set will be introduced separately. Also a PoC
> > > > > > > based on the current version of IPE can be provided.
> > > > > >
> > > > > > I'm not sure we want to implement a cache as a LSM. I'm sure it would
> > > > > > work, but historically LSMs have provided some form of access control,
> > > > > > measurement, or other traditional security service. A digest cache,
> > > > > > while potentially useful for a variety of security related
> > > > > > applications, is not a security service by itself, it is simply a file
> > > > > > digest storage mechanism.
> > > > >
> > > > > Uhm, currently the digest_cache LSM is heavily based on the LSM
> > > > > infrastructure:
> > > >
> > > > I understand that, but as I said previously, I don't believe that we
> > > > want to support a LSM which exists solely to provide a file digest
> > > > cache. LSMs should be based around the idea of some type of access
> > > > control, security monitoring, etc.
> > > >
> > > > Including a file digest cache in IMA, or implementing it as a
> > > > standalone piece of kernel functionality, are still options. If you
> > > > want to pursue this, I would suggest that including the digest cache
> > > > as part of IMA would be the easier of the two options; if it proves to
> > > > be generally useful outside of IMA, it can always be abstracted out to
> > > > a general kernel module/subsystem.
> > >
> > > Ok. I thought about IPE and eBPF as potential users. But if you think
> > > that adding as part of IMA would be easier, I could try to pursue that.
> >
> > It isn't clear to me how this would interact with IPE and/or eBPF, but
> > if you believe there is value there I would encourage you to work with
> > those subsystem maintainers. If the consensus is that a general file
> > digest cache is useful then you should pursue the digest cache as a
> > kernel subsystem, just not a LSM.
> 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.
>
> I guess I will go for the IMA route...
This thread brings up an issue that we have been thinking about but
has been on the back burner.
Roberto, I'm assuming you have seen our TSEM submissions go by. Our
V4 release will be immediately after the Fourth of July holiday week
here in the states.
Since TSEM implements a generic security modeling framework for the
kernel, it ends up implementing a superset of IMA functionality. That
required us to implement our own file digest generation and cacheing
infrastructure.
Given the trajectory that things are on with respect to security,
there is only going to be more demand for file digests and their
associated cacheing. Doesn't seem like it makes a lot of sense to
have multiple teams replicating what is largely the same
functionality.
If your group would have interest, we would certainly be willing to
entertain conversations on how we could collaborate to brew up
something that would be of mutual benefit to everyone who has a need
for this type of infrastructure.
As you noted, consumers of the BPF LSM would also be a clear candidate
for generic infrastructure. One of the issues blocking a BPF based
integrity implementation is that BPF itself is not going to be able
generate digests on its own. So it would seem to make sense to have
whatever gets built have a kfunc accessible API. Plenty of other
additional warts on that front as well but getting access to digests
is the necessary starting point.
Given what we have seen with IMA's challenge with respect to overlayfs
issues and file versioning issues in general, it would seem to be of
profit to have all these issues addressed uniformally and in one
place.
Since virtually everything that is accessing this infrastructure is
going to be an LSM, we would envision API's out of a common
infrastructure, invoked by the event handlers of the various LSM's
interested in integrity information, driving the cache generation and
maintenance. That would seem to have all of the benefits of being
implemented by the LSM infrastructure without necessarily being an
'LSM' in and of itself.
We assume that everyone would want to maintain the O(1) lookup
characteristics of what the LSM inode blob mechanism provides. We
would presume that a common cacheing architecture would return a
pointer to the structure that the digest cache maintains describing
the various digests associated with the contents of a file, as there
will be a need for multiple digest support, when an LSM hands the
cache an inode referencing a file. An LSM could then place that
pointer in its own inode blob for future reference.
Either that, probably better, stick a pointer into the inode structure
itself that references it's digest cache object and it would get
populated by the first event that opens the associated file.
> Roberto
So an open invitation to anyone that would want to discuss
requirements around a common implementation.
Have a good weekend.
As always,
Dr. Greg
The Quixote Project - Flailing at the Travails of Cybersecurity
https://github.com/Quixote-Project
