Re: [RFC][Patch 1/6] integrity: new hooks

[Serge E. Hallyn]

Quoting Valdis.Kletnieks@xxxxxx (Valdis.Kletnieks@xxxxxx):
> On Thu, 08 Mar 2007 12:46:47 CST, "Serge E. Hallyn" said:
> > I think it should be done as both.  The part which measures the
> > integrity of files should be an integrity subsystem.  The part which
> > uses those results to either allow/refuse actions or take some other
> > action (i.e. shut down the system) should be an lsm.
> 
> That would be good - the allow/deny parts, being security, can use the
> existing LSM hooks, and the integrity part can use the LIM hooks.

Yes, the only problem is that there will still be 'duplication' at some
call sites.  For instance even if something is only doing measurements, at
setxattr, for instance, it still needs to be able to refuse a change if
it can't allocate memory to store measurement data.  So we still might
need an fsnotify-like approach to consolidate security and integrity
hooks.  (As Mimi pointed out, I guess it'll have to make sure to call
the security ones first)

I suppose something more clever might be doable - for instance since we
are pairing the measurement module with an enforcement module, the
enforcement module could kmalloc() what the measurement module will need
for data and return -ENOMEM if need be, then the measurement module just
fills the data in.  If there's no place for it to store the data, then
it knows that the enforcement module must be ok not having that data.

> Umm... wait a minute - *what* Linux Integrity Module hooks? :)

-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/