Messages in this thread | | | Subject | Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks | From | Stephen Smalley <> | Date | Wed, 19 Apr 2006 11:26:57 -0400 |
| |
On Wed, 2006-04-19 at 10:52 -0400, David Safford wrote: > 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.
Ok, either way removal of LSM isn't an issue in that case.
> 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.
My concerns with low water mark were noted in http://marc.theaimsgroup.com/?l=linux-security-module&m=113232319627338&w=2 http://marc.theaimsgroup.com/?l=linux-security-module&m=113319033229209&w=2 http://marc.theaimsgroup.com/?l=linux-security-module&m=113327082228907&w=2
I also pointed out examples of how low water mark has compatibility/useability problems of its own in that discussion. And it has only has the two options available to all such "simple" models when reality conflicts with their model: preserve the model and break the functionality or make the process a trusted subject fully capable of violating the model (at which point you are only pretending to enforce the model). Versus being able to configure the policy to match reality, as in SELinux.
> 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.
If such models can demonstrate their viability, then you can ultimately submit a patch to extend SELinux/Flask to support them - I have no problem with that (again, if they can be shown to be viable and implementation is correct). But first you have to show that. In the meantime, your work can be done via a kernel patch that you carry; it doesn't justify keeping LSM in mainline. Note too that LSM seems to me to be harmful to such work, because many of the mistakes you made in the first place might have been avoided if you had started by extending the existing SELinux/Flask infrastructure (which had much more defined semantics) than using LSM (which is just a skeletal framework with no real semantics). Plus it might have encouraged you to propose each change as a small patch to SELinux along the way and gotten you valuable feedback sooner.
-- Stephen Smalley National Security Agency
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |