Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks

David Safford
2006-04-19T14:52:22Z

On Mon, 2006-04-17 at 16:02 -0400, Stephen Smalley wrote:
> At the conclusion of the last round of discussions on slim-evm-ima on
> list, it was the case that:

> ima was no longer an issue, as it had already ceased being a separate
> LSM,

Agreed. Integrity attestation clearly needed to be tightly coupled with
integrity measurement.

> it was demonstrated that evm needed to be tightly coupled with any LSM
> in order to work correctly and efficiently, and it seemed to be accepted
> that evm needed to be turned from a separate LSM into a set of support
> functions for use by a LSM (as well as having many other design and
> implementation problems to resolve to be truly useable),

It was certainly agreed that integrity needed to be a separate service
available to any access control module, with nothing specific to SLIM,
and that a number of design and implementation problems had to be fixed.
During testing we also found a number of other bugs which weren't raised
on the list, which had to be fixed. (That's what has taken us so long to
post a new version.) As to whether it should be tightly coupled to an
LSM module, or should be a separate service with its own kernel hooks,
I think was not settled.

> - it was argued that slim was broken-by-design and no one was willing or
> able to refute that position.
>
> Hardly a strong case for LSM...

I seem to recall a number of people arguing for the low water-mark
integrity policy as one which provides a simple, user friendly
policy, one which has been demonstrated and tested not only by
SLIM, but also with predecessors, such as LOMAC.

I do understand and respect the selinux position against dynamic
labels, since they require revocation, and particularly since at
that time, we had not implemented revocation of mmap access. We
have been quietly studying, fixing, and testing the design and
implementation errors pointed out earlier, and still feel strongly
that low water-mark policies have a place, particularly in client
systems.

Since selinux (by choice) cannot implement policies with dynamic labels,
I believe LSM is important for work in alternative access control
models, like low water-mark, to continue.

dave safford