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

[Stephen Smalley]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/