On Thu, Nov 16, 2023 at 4:47 AM Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > On Wed, 2023-11-15 at 23:33 -0500, Paul Moore wrote: > > On Nov 7, 2023 Roberto Sassu <roberto.sassu@xxxxxxxxxxxxxxx> wrote: > > > > > > In preparation for moving IMA and EVM to the LSM infrastructure, introduce > > > the file_pre_free_security hook. > > > > > > IMA calculates at file close the new digest of the file content and writes > > > it to security.ima, so that appraisal at next file access succeeds. > > > > > > LSMs could also take some action before the last reference of a file is > > > released. > > > > > > The new hook cannot return an error and cannot cause the operation to be > > > reverted. > > > > > > Signed-off-by: Roberto Sassu <roberto.sassu@xxxxxxxxxx> > > > Acked-by: Casey Schaufler <casey@xxxxxxxxxxxxxxxx> > > > Reviewed-by: Mimi Zohar <zohar@xxxxxxxxxxxxx> > > > --- > > > fs/file_table.c | 1 + > > > include/linux/lsm_hook_defs.h | 1 + > > > include/linux/security.h | 4 ++++ > > > security/security.c | 11 +++++++++++ > > > 4 files changed, 17 insertions(+) > > > > > > diff --git a/fs/file_table.c b/fs/file_table.c > > > index de4a2915bfd4..64ed74555e64 100644 > > > --- a/fs/file_table.c > > > +++ b/fs/file_table.c > > > @@ -385,6 +385,7 @@ static void __fput(struct file *file) > > > eventpoll_release(file); > > > locks_remove_file(file); > > > > > > + security_file_pre_free(file); > > > > I worry that security_file_pre_free() is a misleading name as "free" > > tends to imply memory management tasks, which isn't the main focus of > > this hook. What do you think of security_file_release() or > > security_file_put() instead? > > security_file_release() would be fine for me. Okay, assuming no objections for anyone else let's go with that. Thanks for indulging my naming nitpick :) -- paul-moore.com
