TOMOYO's pull request for v6.12

[Paul Moore]

On Sat, Oct 5, 2024 at 2:58 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
> On 10/5/2024 10:02 AM, Dr. Greg wrote:

...

> > As we have evolved TSEM we realized that we actually want to be first,
> > if that isn't also a coveted position.
>
> The current thought is that we frown on an LSM desiring a specific
> ordering and would probably reject one that required it.

Agreed.  We do have a couple LSMs that do require some specific
ordering rules, but those are typically for safety related reasons
realized after the fact, or some legacy/compat reason.  I'm not going
to say we would 100% reject an LSM that required a specific ordering,
but there would be a *lot* of questions about that requirement during
review :)

> > For example, internally, we have TSEM 'models' whose only function is
> > to validate that the extended security attributes of an inode match
> > what the workload was unit tested to, in order to thwart offline
> > modification attacks.  In this case you want TSEM to be running ahead
> > of the security attribute based models, since presumably, you would
> > not want those models making a decision on extended attributes that
> > have been modified.

In this particular case it shouldn't matter from an access control
perspective.  Sure, you might end up doing some extra work in a LSM if
TSEM were to occur later in the ordering and ends up rejecting the
operation, but that really is no different from any other case where a
LSM later in the ordering rejects an operation that was allowed by all
the others before it.  The important thing to remember is that just
because a given LSM authorizes an operation, it does not mean the
operation will successfully run to completion.  Even in the single LSM
case, with the LSM access control happening so early in the code path,
there are often multiple ways an operation can fail, e.g. -ENOMEM.

-- 
paul-moore.com