On 07/10/2021 20:37, Mimi Zohar wrote: > On Thu, 2021-10-07 at 20:29 +0200, Mickaël Salaün wrote: >> On 07/10/2021 00:03, Kees Cook wrote: >>> On Fri, Apr 09, 2021 at 07:15:42PM +0200, Mickaël Salaün wrote: >>>> 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@xxxxxxxxxxx/ >> >> Some Signed-off-by would be appreciated. :) >> > >>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]. > >>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 > >>> >>> 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 >>> > >
