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

[David Safford]

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




-
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/