lkml.org 
[lkml]   [2008]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][Patch 5/5]integrity: IMA as an integrity service provider
From
Date
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


\
 
 \ /
  Last update: 2008-06-24 18:33    [W:0.136 / U:1.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site