On 07/10/2021 20:37, Mimi Zohar wrote:

On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote:

quoted

On 07/10/2021 00:03, Kees Cook wrote:

quoted

On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote:

quoted

There was no new reviews, probably because the FS maintainers were busy,
and I was focused on Landlock (which is now in -next), but I plan to
send a new patch series for trusted_for(2) soon.

Hi!

Did this ever happen? It looks like it's in good shape, and I think it's
a nice building block for userspace to have. Are you able to rebase and
re-send this?

I just sent it:
https://lore.kernel.org/all/20211007182321.872075-1-mic@digikod.net/ (local)

Some Signed-off-by would be appreciated. :)

quoted

From the cover letter, 

It is important to note that this can only enable to extend access
control managed by the kernel.  Hence it enables current access control
mechanism to be extended and become a superset of what they can
currently control.  Indeed, the security policy could also be delegated
to an LSM, either a MAC system or an integrity system.  For instance,
this is required to close a major IMA measurement/appraisal interpreter
integrity gap by bringing the ability to check the use of scripts [1].
Other uses are expected, such as for magic-links [2], SGX integration
[3], bpffs [4].

quoted

From a quick review of the code, I don't see a new security hook being

defined to cover these use cases.

Indeed, there is no new hook because it would require to implement it
with a current LSM. This first step is a standalone implementation that
is useful as-is but open the way to add a new LSM hook in this new
syscall. That would be a second step for any LSM developer to implement
if interested.

thanks,

Mimi

quoted

quoted

I've tended to aim these things at akpm if Al gets busy. (And since
you've had past review from Al, that should be hopefully sufficient.)

Thanks for chasing this!

-Kees