On Tue, Jan 31, 2023 at 04:49:44PM +0100, Roberto Sassu wrote:

On Mon, 2023-01-30 at 14:57 -0800, Fan Wu wrote:

quoted

From: Deven Bowers <redacted>

IPE must have a centralized function to evaluate incoming callers
against IPE's policy. This iteration of the policy against the rules
for that specific caller is known as the evaluation loop.

Not sure if you check the properties at every access.

quoted

From my previous comments (also for previous versions of the patches)

you could evaluate the property once, by calling the respective
functions in the other subsystems.

Then, you reserve space in the security blob for inodes and superblocks
to cache the decision. The format could be a policy sequence number, to
ensure that the cache is valid only for the current policy, and a bit
for every hook you enforce.

Thanks for raising this idea. I agree that if the property evaluation
leads to a performance issue, it will be better to cache the evaluation
result. But for this version, all the property evaluations are simple,
so it is just as fast as accessing a cache. Also, for the initial
version we prefer to keep the patch as minimal as possible. 

If the policy evolved to be super complex and the evaluation becomes
a bottleneck, cache support will absolutely be the right way we will go.
-Fan

Also, currently you rely on the fact that the properties you defined
are immutable and the immutability is guaranteed by the other
subsystems, so no write can occur.

But if you remove this limitation, the immutability is not guaranteed
anymore by the other subsystems (for example if a file is in an ext4
filesystem), the LSM needs to take extra care to ensure that the
properties are still verified. This would be required for example if
IPE is used in conjuction with DIGLIM.

In my opinion, IPE value would increase if the generic enforcement
mechanism is property-agnostic.

Roberto