On Wed, 2011-11-16 at 15:49 -0500, Eric Paris wrote:
> On Wed, 2011-11-16 at 15:24 -0500, Mimi Zohar wrote:
> > On Wed, 2011-11-16 at 12:27 -0500, Eric Paris wrote:
>
> > > > +int ima_file_premmap(struct file *file, unsigned long prot)
> > > > +{
> > > > + int rc;
> > > > +
> > > > + if (!file)
> > > > + return 0;
> > > > + if (prot & PROT_EXEC)
> > > > + rc = process_measurement(file, file->f_dentry->d_name.name,
> > > > + MAY_EXEC, FILE_PREMMAP);
> > > > + return 0;
> > > > +}
> > >
> > > Here lets call the helper above, but instead of FILE_PREMMAP, lets use
> > > the correct FILE_MMAP or FILE_BPRM, which is going to have to come as a
> > > third argument, right?
> >
> > Ok, thanks for the review.
>
> Actually it just dawned on me, that what I think we really learned here
> is that we have the hooks in the wrong place. If we are going to
> sprinkle the code with ima_file_premmap() maybe we should just actually
> do ALL of the work in this new hook? Throw the security_file_mmap() IMA
> hook out the window and just actually do the whole process_measurement()
> work in this new hook? You'll have to see if that's better. But it
> sucks to allocate an object just to have to look it up 100 instructions
> later. Why not just do the work when we do the allocation and not come
> back a second time?
>
> -Eric
We want to wait until the file is locked and can't be modified before we
measure it. Am looking for where that is done.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
