Messages in this thread | | | Subject | Re: [RFC][Patch 5/5]integrity: IMA as an integrity service provider | From | david safford <> | Date | Tue, 24 Jun 2008 12:28:50 -0400 |
| |
On Wed, 2008-05-28 at 01:22 -0700, Andrew Morton wrote:
> - I see lots of user file I/O being done from within the kernel. > This makes eyebrows raise. Also some other eyebrow-raising > file-related things in there. > > Generally: the code is all moderately intrusive into the VFS and this > sort of thing does need careful explanation and justification, please. > Once we have some understanding of what you're trying to achieve here > we will inevitably ask "can't that be done in userspace". So it would > be best if your description were to preemptively answer all that. > > Sorry about this delayed response - we are about to repost for RFC, and noticed we missed responding to this.
The Trusted Computing (TPM) model requires that all files be measured, (hashed) and the measurement committed to the hardware TPM before any data of the file is accessed in any way. In addition, if the measurement is incorrect, all access to the file must be denied.
This requirement parallels the LSM mandatory access control decisions in the inode_permission, bprm, and mmap hooks, and naturally leads to IMA hooks in the same locations, with similar functionality, but with the addition of hashing the data. The code would have to significantly more complex to do the hashing at these points through userspace.
In addition, doing the hashing in userspace gives significantly poorer performance. With in-kernel hashing, at boot time, we typically measure some six thousand files with less than 10% (5 seconds) overhead, which is acceptable to most users. Anything much slower can be annoying enough that users will turn the measurement off.
dave safford
| |