[lkml]   [2007]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel
    "Serge E. Hallyn" <> writes:

    > Quoting Eric W. Biederman (
    >> Perform the split up you talked about above and move the table
    >> matching into the LSM hooks.
    >> Use something like the iptables action and match to module mapping
    >> code so we can have multiple modules compiled in and useable at the
    >> same time with the LSM hooks.
    >> I think it is firmly established that selling SElinux to everyone is
    >> politically untenable. However enhancing the LSM (even if it is
    >> mostly selinux code movement down a layer) I think can be sold.
    >> If I could run Serge's isolation code and selinux rules at the same
    >> time that would be interesting.
    > But given that namespaces are making it upstream, what else is to be
    > gained from the bsdail module? What exactly are you looking for?

    Good question. I keep tripping over the LSM hooks, and I have the
    distinct impression that part of the current contention and lack of
    agreement is simply the way things are current factored. So I'm
    putting for a constructive suggestion that has the possibility of
    going somewhere.

    > 1. are you looking to cover all the corner cases - i.e. prevent killing
    > a process in another namespace through F_SETOWN or mqueue, etc?

    I'm looking towards this yes. There are times when we deliberately
    allow mixing of things by the definition of what namespaces are and
    there are some use cases where people don't want this.

    > 2. are you looking for a potentially easier fix to the current absence
    > of isolation in the user namespace?

    No. I'm not even worrying about the user namespace until it resembles
    complete. Currently I just view it as a stub because as is, the
    security namespace is pretty much useless for any case I think about.
    We still have way to many cases where the kernel treats different
    names as the same name.

    > 3. are you just generally looking to make lsm/selinux easier for
    > yourself to configure?

    Well. I'm trying to make the LSM more useful to hack on and configure,
    and much less contentions for ordinary people to use.

    There is one issue with sockets that has come up where there are
    people who really want to filter things at connect and bind time.
    The LSM is so inflexible the only sane suggestion at the time was
    to duplicate the LSM hooks and add an new iptable style table
    for making that decision.

    Also I'm thinking towards what do we have to do isolate the security
    module stuff in the context of a namespace. So that a person in
    a container can setup their own rules that further restrict the

    So far I'm not ready to do anything yet but I'm keeping a weather eye
    on the situation so I have a clue what I'm go.

    > If 1, an selinux policy should cover you. So you can then skip to 3.
    > Or, alternatively, I do plan - as soon as my free time clears up a bit -
    > on demonstrating how to write some selinux policy to create a secure
    > container based on current -mm + your experimental network namespace
    > patches.

    Thanks that sounds interesting.

    > If 3, then selinux policy modules may actually help you, else either
    > a new LSM (maybe like LIDS) or a userspace tool which is a front-end to
    > selinux policy, emulating the iptables rules formats, may be what you
    > want?

    I don't want to have to choose my LSM at compile time. I want to
    add support into the kernel at compile time and be able to configure
    it before I go multi-user. I know this kind of architecture is
    achievable because iptables allows it.

    When I conceive as the security modules as just a firewall between
    applications on my own box I think, oh yeah this is no big deal,
    I might want to limit something that way some time. These are just
    some additional rules on when to return -EPERM. So I ask myself why
    is this situation much less flexible and much harder to use then our
    network firewall code?

    >> My impression is that selinux is one monolithic blob that doesn't
    >> allow me to incrementally add matching or action features that I
    >> find interesting.
    > Actually with policy modules it gets much much better. I have in fact
    > been able to pretty easily write a short policy module to, say, create
    > an selinux user which ran as root and had full access to the system to
    > do system setup for automated testing. There is a learning curve in
    > having to look at existing modules for maybe a few days to get started,
    > but once you get started the policy modules do make it very easy to
    > add to current policy.

    Ok. Interesting. Are these kernel modules?

    Still while I get the general impression that selinux seems to be
    very close to a generic solution, and that selinux more or less has
    the architecture we might want. I don't get the impression that
    selinux does this at a level that is open to other people doing
    interesting things.

    So I still ask the question can we move this functionality down to
    the LSM in a way that will solve the composition problem between
    multiple security modules?

    It really seems to me that the LSM as currently structured creates
    a large barrier to entry for people who have just this little thing
    they want to do that is not possible with any existing security

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-10-08 19:23    [W:0.030 / U:81.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site