On Mon, Jun 08, 2020 at 09:22:06AM -0400, Mimi Zohar wrote: > On Mon, 2020-06-08 at 06:16 -0700, Matthew Wilcox wrote: > > On Mon, Jun 08, 2020 at 09:03:21AM -0400, Mimi Zohar wrote: > > > With this new design of not using a private vmalloc, will the file > > > data be accessible prior to the post security hooks? From an IMA > > > perspective, the hooks are used for measuring and/or verifying the > > > integrity of the file. > > > > File data is already accessible prior to the post security hooks. > > Look how kernel_read_file works: > > > > ret = deny_write_access(file); > > ret = security_kernel_read_file(file, id); > > *buf = vmalloc(i_size); > > bytes = kernel_read(file, *buf + pos, i_size - pos, &pos); > > ret = security_kernel_post_read_file(file, *buf, i_size, id); > > > > kernel_read() will read the data into the page cache and then copy it > > into the vmalloc'd buffer. There's nothing here to prevent read accesses > > to the file. > > The post security hook needs to access to the file data in order to > calculate the file hash. The question is whether prior to returning > from kernel_read_file() the caller can access the file data. Whether you copy the data (as today) or map it (as I'm proposing), the data goes into the page cache. It's up to the security system to block access to the page cache until it's been verified.
