lkml.org 
[lkml]   [2006]   [Apr]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks
    From
    Date
    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/

    \
     
     \ /
      Last update: 2006-04-19 17:25    [W:4.314 / U:0.248 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site