Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel - Kernel

This is a discussion on Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel - Kernel ; On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote: > --- Kyle Moffett wrote: > > > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote: > > > Kyle Moffett writes: > > > > > >> On ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

  1. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

    On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
    > --- Kyle Moffett wrote:
    >
    > > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
    > > > Kyle Moffett writes:
    > > >
    > > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:
    > > >>> SElinux is not all encompassing or it is generally
    > > >>> incomprehensible I don't know which. Or someone long ago would
    > > >>> have said a better way to implement containers was with a
    > > >>> selinux ruleset, here is a selinux ruleset that does that.
    > > >>> Although it is completely possible to implement all of the
    > > >>> isolation with the existing LSM hooks as Serge showed.
    > > >>
    > > >> The difference between SELinux and containers is that SELinux (and
    > > >> LSM as a whole) returns -EPERM to operations outside the scope of
    > > >> the subject, whereas containers return -ENOENT (because it's not
    > > >> even in the same namespace).
    > > >
    > > > Yes. However if you look at what the first implementations were.
    > > > Especially something like linux-vserver. All they provided was
    > > > isolation. So perhaps you would not see every process ps but they
    > > > all had unique pid values.
    > > >
    > > > I'm pretty certain Serge at least prototyped a simplified version
    > > > of that using the LSM hooks. Is there something I'm not remember
    > > > in those hooks that allows hiding of information like processes?
    > > >
    > > > Yes. Currently with containers we are taking that one step farther
    > > > as that solves a wider set of problems.

    > >
    > > IMHO, containers have a subtly different purpose from LSM even though
    > > both are about information hiding. Basically a container is
    > > information hiding primarily for administrative reasons; either as a
    > > convenience to help prevent errors or as a way of describing
    > > administrative boundaries. For example, even in an environment where
    > > all sysadmins are trusted employees, a few head-honcho sysadmins
    > > would get root container access, and all others would get access to
    > > specific containers as a way of preventing "oops" errors. Basically
    > > a container is about "full access inside this box and no access
    > > outside".
    > >
    > > By contrast, LSM is more strictly about providing *limited* access to
    > > resources. For an accounting business all client records would
    > > grouped and associated together, however those which have passed this
    > > year's review are read-only except by specific staff and others may
    > > have information restricted to some subset of the employees.
    > >
    > > So containers are exclusive subsets of "the system" while LSM should
    > > be about non-exclusive information restriction.

    >
    > Yes. Isolation is a much simpler problem than access control.
    >
    > > >>> We also have in the kernel another parallel security mechanism
    > > >>> (for what is generally a different class of operations) that has
    > > >>> been quite successful, and different groups get along quite
    > > >>> well, and ordinary mortals can understand it. The linux
    > > >>> firewalling code.
    > > >>
    > > >> Well, I wouldn't go so far as the "ordinary mortals can understand
    > > >> it" part; it's still pretty high on the obtuse-o-meter.
    > > >
    > > > True. Probably a more accurate statement is:`unix command line
    > > > power users can and do handle it after reading the docs. That's
    > > > not quite ordinary mortals but it feels like it some days. It
    > > > might all be perception...

    > >
    > > I have seen more *wrong* iptables firewalls than I've seen correct
    > > ones. Securing TCP/IP traffic properly requires either a lot of
    > > training/experience or a good out-of-the-box system like Shorewall
    > > which structures the necessary restrictions for you based on an
    > > abstract description of the desired functionality. For instance what
    > > percentage of admins do you think could correctly set up their
    > > netfilter firewalls to log christmas-tree packets, smurfs, etc
    > > without the help of some external tool? Hell, I don't trust myself
    > > to reliably do it without a lot of reading of docs and testing, and
    > > I've been doing netfilter firewalls for a while.
    > >
    > > The bottom line is that with iptables it is *CRITICAL* to have a good
    > > set of interface tools to take the users' "My system is set up
    > > like..." description in some form and turn it into the necessary set
    > > of efficient security rules. The *exact* same issue applies to
    > > SELinux, with 2 major additional problems:
    > >
    > > 1) Half the tools are still somewhat beta-ish and under heavy
    > > development. Furthermore the semi-official reference policy is
    > > nowhere near comprehensive and pretty ugly to read (go back to the
    > > point about the tools being beta-ish).
    > >
    > > 2) If you break your system description or translation tools then
    > > instead of just your network dying your entire *system* dies.
    > >
    > >
    > > >>> The linux firewalling codes has hooks all throughout the
    > > >>> networking stack, just like the LSM has hooks all throughout the
    > > >>> rest of linux kernel. There is a difference however. The linux
    > > >>> firewalling code in addition to hooks has tables behind those
    > > >>> hooks that it consults. There is generic code to walk those
    > > >>> tables and consult with different kernel modules to decide if we
    > > >>> should drop a packet. Each of those kernel modules provides a
    > > >>> different capability that can be used to generate a firewall.
    > > >>
    > > >> This is almost *EXACTLY* what SELinux provides as an LSM module.
    > > >> The one difference is that with SELinux some compromises and
    > > >> restrictions have been made so that (theoretically) the resulting
    > > >> policy can be exhaustively analyzed to *prove* what it allows and
    > > >> disallows. It may be that SELinux should be split into 2 parts,
    > > >> one that provides the underlying table-matching and the other
    > > >> that uses it to provide the provability guarantees. Here's a
    > > >> direct comparison:
    > > >>
    > > >> netfilter:
    > > >> (A) Each packet has src, dst, port, etc that can be matched
    > > >> (B) Table of rules applied sequentially (MATCH => ACTION)
    > > >> (C) Rules may alter the properties of packets as they are routed/
    > > >> bridged/etc
    > > >>
    > > >> selinux:
    > > >> (A) Each object has user, role, and type that can be matched
    > > >> (B) Table of rules searched by object parameters (MATCH => allow/
    > > >> auditallow/transition)
    > > >> (C) Rules may alter the properties of objects through transition
    > > >> rules.
    > > >
    > > > Ok. There is something here.
    > > >
    > > > However in a generic setup, at least role would be an extended
    > > > match criteria provided by the selinux module. It would not be a
    > > > core attribute. It would need to depend on some extra
    > > > functionality being compiled in.

    > >
    > > Now see I think *THAT* is where Casey should be going with his SMACK
    > > code. Don't add another LSM, start looking at SELinux and figuring
    > > out what parts he does not need and how they can be parameterized out
    > > at build time for smaller systems.

    >
    > Good suggestion. In fact, that is exactly how I approached my
    > first two attempts at the problem. What you get if you take that
    > route is an imposing infrastructure that has virually nothing
    > to do and that adds no value to the solution. Programming to the
    > LSM interface, on the other hand, allowed me to drastically reduce
    > the size and complexity of the implementation.


    It would be interesting to see the result of those first two attempts
    (even if they didn't get very far) just to see your approach and what
    obstacles you ran up against.

    > > On the other hand, the "user" and "role" fields in SELinux are
    > > already fairly flexible. The one constant is that user=>role and
    > > role=>type must both be allowed for a label to be valid. Other than
    > > that, the constraints specify what must be true for a transition to
    > > be allowed. For example the standard strict reference policy
    > > includes this bit:
    > >
    > > constrain process transition (
    > > (u1 == u2) or
    > > (t1 == can_change_process_identity and t2 == process_user_target) or
    > > (t1 == cron_source_domain and (t2 == cron_job_domain or u2 ==
    > > system_u)) or
    > > (t1 == can_system_change and u2 == system_u) or
    > > (t1 == process_uncond_exempt)
    > > );
    > >
    > > Basically all constraints on a particular access vector must be
    > > satisfied for that to be allowed (in addition to other things). For
    > > the above example, a process running exec() may only change its user
    > > if one of the following:
    > >
    > > * It's a login-like program and is starting a user entrypoint
    > > * It's a cron-like program and is starting a user or system cronjob
    > > * It's a process allowed to start system processes (admin runs
    > > initscripts)
    > > * It's unconditionally exempt
    > >
    > > By creating types and assigning meaningful attributes to those types
    > > you may restrict the changing of the "user" and "role" however you
    > > would like, including not at all.
    > >
    > > Really SELinux is just a fairly elaborate security state-machine.
    > > Each process on the system is in a given "state", defined by its
    > > label, and "state transitions" are only allowed based on the rules
    > > defined in the database. Since there are 4 extremely common security
    > > models that people like to combine there are 4 fields in each SELinux
    > > label:
    > > (A) User: User A may not poke user B's processes/data, even if
    > > they happen to be running in the same UNIX UID
    > > (B) Role: Users may only perform operations for the role they are
    > > currently logged in as
    > > (C) Type-enforcement: An apache process may only read files that
    > > it needs to operate correctly
    > > (D) Multi-level: Top-secret data can't magically become
    > > unclassified
    > >
    > > Perhaps the thing to do would be to make it possible to compile out
    > > the portions which people don't want. That would certainly satisfy
    > > Casey, he would build only the "Type-enforcement" portion or only the
    > > "Multi-level" portion and be able to do exactly the same things he
    > > does now with a bit finer granularity of operations. By defining the
    > > lists of operations he cares about for "r" (read), "w" (write),
    > > "x" (exec), "a" (append), and requires-capabilities, you can just
    > > give those permissions directly in a simplified SELinux-type policy.

    >
    > But Kyle, it's already possible to compile out the part I don't
    > want. I configure SELinux off and away I go.
    >
    > Smack is not a subset of SELinux, it behaves differently. SELinux
    > has a policy that is program behavior oriented, Smack is strictly
    > subjet/object oriented. Your 4 components (A-D) are meaningless to
    > Smack.


    To clarify, SELinux is also based on subjects and objects grouped into
    equivalence classes (labels), and the granularity at which one applies
    protection is configurable, so you can certainly have very
    coarse-grained labels that don't require any specific knowledge of
    application behavior. A type is just a security equivalence class - it
    doesn't have to map to an application at all.

    Also, the idea behind SELinux was that its policy engine (security
    server, security/selinux/ss/*) could be replaced with other
    implementations without affecting the rest of SELinux if someone wanted
    to try radically different logic. The interface to that policy engine
    is itself general and not tied to TE.

    > > >>> I'm not yet annoyed enough to go implement an iptables like
    > > >>> interface to the LSM enhancing it with more generic mechanism to
    > > >>> make the problem simpler, but I'm getting there. Perhaps next
    > > >>> time I'm bored.
    > > >>
    > > >> I think a fair amount of what we need is already done in SELinux,
    > > >> and efforts would be better spent in figuring out what seems too
    > > >> complicated in SELinux and making it simpler.

    >
    > The granularity and consequently the size of the policy specificiation
    > result in policies that are too complicated. Tieing the policy to the
    > expected behavior of specific applications adds to the complexity.


    Well, it reveals the complexity already present in the system, and gives
    you the option of controlling it. Your choice as to at what granularity
    to apply it.

    > SELinux is designed to increase in complexity as it evolves. Making
    > it simpler would conflict with the design goal of finer granularity.
    >
    > > >> Probably a fair amount of that just means better tools.

    >
    > Now what kind of tools are you talking about? Static analysis?
    > Data flow diagrammers for Java?
    >
    > > > How about thinking of it another way.
    > > >
    > > > 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.

    >
    > That would be silly. Smack uses a significantly smaller set of hooks
    > than SELinux requires and still does interesting things. We went through
    > the "replace LSM with the SELinux interface" exercise a couple years
    > ago, I would hate to have to regurgitate all those discussions.


    I don't think Eric is proposing replacing LSM with the SELinux interface
    as it exists today, but rather making LSM more Netfilter-like and
    radically refactoring SELinux (and any other security module) to consist
    of a chain of smaller modules that are more general and reusable, and
    that can be composed and applied in interesting ways via an
    iptables-like interface. I'm not sure what that would look like
    exactly, but it seems reasonable to explore.

    One of the things left unresolved with LSM is userland API, and it does
    involve more than just returning EPERM or EACCES to applications. You
    already have patched ls and sshd programs, and have acknowledged the
    need for more userland modifications to ultimately achieve your own
    goals. If LSM is going to succeed in the kernel, then ultimately you
    need some common API for userland so that you don't need separate
    versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.

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

  2. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel


    --- Stephen Smalley wrote:

    > ...
    >
    > > Good suggestion. In fact, that is exactly how I approached my
    > > first two attempts at the problem. What you get if you take that
    > > route is an imposing infrastructure that has virually nothing
    > > to do and that adds no value to the solution. Programming to the
    > > LSM interface, on the other hand, allowed me to drastically reduce
    > > the size and complexity of the implementation.

    >
    > It would be interesting to see the result of those first two attempts
    > (even if they didn't get very far) just to see your approach and what
    > obstacles you ran up against.


    Woof. It weren't pretty, and I've carefully archived it so as
    to make it hard to go back to for that very reason. Maybe someday.

    > ...
    > > Smack is not a subset of SELinux, it behaves differently. SELinux
    > > has a policy that is program behavior oriented, Smack is strictly
    > > subjet/object oriented. Your 4 components (A-D) are meaningless to
    > > Smack.

    >
    > To clarify, SELinux is also based on subjects and objects grouped into
    > equivalence classes (labels), and the granularity at which one applies
    > protection is configurable, so you can certainly have very
    > coarse-grained labels that don't require any specific knowledge of
    > application behavior. A type is just a security equivalence class - it
    > doesn't have to map to an application at all.
    >
    > Also, the idea behind SELinux was that its policy engine (security
    > server, security/selinux/ss/*) could be replaced with other
    > implementations without affecting the rest of SELinux if someone wanted
    > to try radically different logic. The interface to that policy engine
    > is itself general and not tied to TE.


    The ss interface provides no advantage over the LSM interface that
    I can see.

    > > > >>> I'm not yet annoyed enough to go implement an iptables like
    > > > >>> interface to the LSM enhancing it with more generic mechanism to
    > > > >>> make the problem simpler, but I'm getting there. Perhaps next
    > > > >>> time I'm bored.
    > > > >>
    > > > >> I think a fair amount of what we need is already done in SELinux,
    > > > >> and efforts would be better spent in figuring out what seems too
    > > > >> complicated in SELinux and making it simpler.

    > >
    > > The granularity and consequently the size of the policy specificiation
    > > result in policies that are too complicated. Tieing the policy to the
    > > expected behavior of specific applications adds to the complexity.

    >
    > Well, it reveals the complexity already present in the system, and gives
    > you the option of controlling it. Your choice as to at what granularity
    > to apply it.


    Which is the same for LSM. There are a bunch of LSM hooks that Smack
    does not need, and going into SELinux code to choose to do nothing
    is pretty pointless.

    > > SELinux is designed to increase in complexity as it evolves. Making
    > > it simpler would conflict with the design goal of finer granularity.
    > >
    > > > >> Probably a fair amount of that just means better tools.

    > >
    > > Now what kind of tools are you talking about? Static analysis?
    > > Data flow diagrammers for Java?
    > >
    > > > > How about thinking of it another way.
    > > > >
    > > > > 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.

    > >
    > > That would be silly. Smack uses a significantly smaller set of hooks
    > > than SELinux requires and still does interesting things. We went through
    > > the "replace LSM with the SELinux interface" exercise a couple years
    > > ago, I would hate to have to regurgitate all those discussions.

    >
    > I don't think Eric is proposing replacing LSM with the SELinux interface
    > as it exists today, but rather making LSM more Netfilter-like and
    > radically refactoring SELinux (and any other security module) to consist
    > of a chain of smaller modules that are more general and reusable, and
    > that can be composed and applied in interesting ways via an
    > iptables-like interface. I'm not sure what that would look like
    > exactly, but it seems reasonable to explore.


    The image that just flashed into my brain had a disturbing
    similarity to STREAMS modules, but spread everywhere, not just
    in the tty code. And anyone who thinks that there are too many
    LSM hooks now would have kittens over this. I don't think it's a
    bad idea, but I don't see how it would change the well documented
    disputes regarding what kinds of security behavior it ought to
    provide for. How would it help AppArmor, for example? I'm willing
    to bet (a beer or equivalence) that anything that helped there
    would face stiff resistance simply because it helped there.

    I could see it working if you restricted the interface to dealing
    with things that have security blobs, or even better to subjects
    and objects. But that's my security mindset, and I think pretty
    much yours, too. It's the policies that don't use good old
    fashioned OrangeBook concepts that have issue, not SELinux or Smack.

    > One of the things left unresolved with LSM is userland API, and it does
    > involve more than just returning EPERM or EACCES to applications. You
    > already have patched ls and sshd programs, and have acknowledged the
    > need for more userland modifications to ultimately achieve your own
    > goals. If LSM is going to succeed in the kernel, then ultimately you
    > need some common API for userland so that you don't need separate
    > versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.


    Smack uses text strings for labels. It's amazing how many of the API
    issues evaporate when the only thing you have to do with your labels is
    compare them and print them. With the labels for processes available
    through /proc, and the labels for most things available via getxattr(2)
    and its variants the API issue seems hard to get worked up about. If
    ls(1) had an option to show selected extended attributes, and it really
    should by now, it wouldn't require fixing at all. Now sshd, login, and
    the rest of the authentification gaggle are going to need policy
    specific behavior so I feel no serious need to provide common API there.
    Smack is designed to make this easy because I had to do it the hard
    way before and didn't like it much.



    Casey Schaufler
    casey@schaufler-ca.com
    -
    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/

  3. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

    Stephen Smalley writes:

    > On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
    >> --- Kyle Moffett wrote:
    >>
    >> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
    >> > > Kyle Moffett writes:
    >> > >
    >> > >> On Oct 04, 2007, at 21:44:02, Eric W. Biederman wrote:


    >> > > Yes. Currently with containers we are taking that one step farther
    >> > > as that solves a wider set of problems.


    >> > So containers are exclusive subsets of "the system" while LSM should
    >> > be about non-exclusive information restriction.

    >>
    >> Yes. Isolation is a much simpler problem than access control.


    Yes. Simple isolation is a different and simpler problem that can be
    solved with the LSM hooks today. I brought it up for the contrast in
    what the LSM hooks can be useful for. Hopefully allowing the LSM
    hooks to be perceived as something other then just hacks for selinux.

    Using a security module for isolation is currently uninteresting
    because it would preclude use of a security module like selinux or
    smack, because we can have at most one security module at a time
    loaded.

    I have seen several other places where a custom LSM would have
    been a good solution but because we don't allow composition solving
    a little problem with the LSm is not interesting enough to allow
    the code to be merged.

    So I see the current structure of the LSM hooks as hindering
    development.

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

    >>
    >> That would be silly. Smack uses a significantly smaller set of hooks
    >> than SELinux requires and still does interesting things. We went through
    >> the "replace LSM with the SELinux interface" exercise a couple years
    >> ago, I would hate to have to regurgitate all those discussions.

    >
    > I don't think Eric is proposing replacing LSM with the SELinux interface
    > as it exists today, but rather making LSM more Netfilter-like and
    > radically refactoring SELinux (and any other security module) to consist
    > of a chain of smaller modules that are more general and reusable, and
    > that can be composed and applied in interesting ways via an
    > iptables-like interface. I'm not sure what that would look like
    > exactly, but it seems reasonable to explore.


    Exactly refactoring security modules into small simple reusable chunks
    to allow reuse. It might look something like selinux chains or it
    might not. Inherently it needs to expose what you can do at the
    existing hook points, and it needs to allow usage by different modules
    that are compiled in at the same time.

    It is certainly the case that you would not need to use all of the
    existing hooks to get something done.

    > One of the things left unresolved with LSM is userland API, and it does
    > involve more than just returning EPERM or EACCES to applications. You
    > already have patched ls and sshd programs, and have acknowledged the
    > need for more userland modifications to ultimately achieve your own
    > goals. If LSM is going to succeed in the kernel, then ultimately you
    > need some common API for userland so that you don't need separate
    > versions of ls, ps, sshd, etc for Smack vs SELinux vs. whatever.


    Likely. Until we have a generalized LSM interface with 1000 config
    options like netfilter I don't expect we will have grounds to talk
    or agree to a common user space interface. Although I could be
    wrong.

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

  4. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel


    --- "Eric W. Biederman" wrote:


    > Likely. Until we have a generalized LSM interface with 1000 config
    > options like netfilter I don't expect we will have grounds to talk
    > or agree to a common user space interface. Although I could be
    > wrong.


    Gulp. I know that many of you are granularity advocates, but I
    have to say that security derived by tweeking 1000 knobs so that
    they are all just right seems a little far fetched to me. I see
    it as poopooing the 3rd and most important part of the reference
    monitor concept, "small enough to analyze". Sure, you can analyse
    the 1000 individual checks, but you'll never be able to describe
    the system behavior as a whole.


    Casey Schaufler
    casey@schaufler-ca.com
    -
    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/

  5. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

    Casey Schaufler writes:

    > --- "Eric W. Biederman" wrote:
    >
    >
    >> Likely. Until we have a generalized LSM interface with 1000 config
    >> options like netfilter I don't expect we will have grounds to talk
    >> or agree to a common user space interface. Although I could be
    >> wrong.

    >
    > Gulp. I know that many of you are granularity advocates, but I
    > have to say that security derived by tweeking 1000 knobs so that
    > they are all just right seems a little far fetched to me. I see
    > it as poopooing the 3rd and most important part of the reference
    > monitor concept, "small enough to analyze". Sure, you can analyse
    > the 1000 individual checks, but you'll never be able to describe
    > the system behavior as a whole.


    Agreed. I wasn't thinking 1000 individual checks but 1000 different
    capabilities, could be either checks or actions, basically fundamental
    different capabilities. Things like CIPSO, or the ability to store a
    security label on a file. I would not expect most security policies
    to use most of them. Neither do I expect Orange book security to
    necessarily be what people want to achieve with the LSM. But I
    haven't looked at it enough detail to know how things should be
    factored, in this case I was simply extrapolating from the iptables
    experience where we do have a very large number of options.

    The real point being is that I would be surprised if we could come
    to an agreement of a common user space API when we can't agree on how
    to compile all of the security modules into the kernel and have them
    play nice with each other.

    Assuming we can achieve security modules playing nice with each other
    using a mechanism similar to iptables, then what needs to be evaluated
    is the specific table configuration we are using on the system, not
    the full general set of possibilities. Further I expect that for the
    truly security paranoid we want the option to disable further table
    changes after the tables have been configured.

    On another side personally I don't see where the idea comes from that
    you can describe system behavior as a whole without analyzing the
    entire kernel. Has there been work on a sparse like tool that I'm
    not aware of to ensure the we always perform the appropriate security
    checks on the user/kernel interface boundary?

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

  6. Re: [PATCH] Version 3 (2.6.23-rc8) Smack: Simplified Mandatory Access Control Kernel

    Quoting Eric W. Biederman (ebiederm@xmission.com):
    > Casey Schaufler writes:
    >
    > > --- "Eric W. Biederman" wrote:
    > >
    > >
    > >> Likely. Until we have a generalized LSM interface with 1000 config
    > >> options like netfilter I don't expect we will have grounds to talk
    > >> or agree to a common user space interface. Although I could be
    > >> wrong.

    > >
    > > Gulp. I know that many of you are granularity advocates, but I
    > > have to say that security derived by tweeking 1000 knobs so that
    > > they are all just right seems a little far fetched to me. I see
    > > it as poopooing the 3rd and most important part of the reference
    > > monitor concept, "small enough to analyze". Sure, you can analyse
    > > the 1000 individual checks, but you'll never be able to describe
    > > the system behavior as a whole.

    >
    > Agreed. I wasn't thinking 1000 individual checks but 1000 different
    > capabilities, could be either checks or actions, basically fundamental
    > different capabilities. Things like CIPSO, or the ability to store a
    > security label on a file. I would not expect most security policies
    > to use most of them. Neither do I expect Orange book security to
    > necessarily be what people want to achieve with the LSM. But I
    > haven't looked at it enough detail to know how things should be
    > factored, in this case I was simply extrapolating from the iptables
    > experience where we do have a very large number of options.
    >
    > The real point being is that I would be surprised if we could come
    > to an agreement of a common user space API when we can't agree on how
    > to compile all of the security modules into the kernel and have them
    > play nice with each other.
    >
    > Assuming we can achieve security modules playing nice with each other
    > using a mechanism similar to iptables, then what needs to be evaluated
    > is the specific table configuration we are using on the system, not
    > the full general set of possibilities. Further I expect that for the
    > truly security paranoid we want the option to disable further table
    > changes after the tables have been configured.
    >
    > On another side personally I don't see where the idea comes from that
    > you can describe system behavior as a whole without analyzing the
    > entire kernel. Has there been work on a sparse like tool that I'm
    > not aware of to ensure the we always perform the appropriate security
    > checks on the user/kernel interface boundary?


    Yup, see the top of http://www.research.ibm.com/vali/

    Pretty cool work that really should be continued.

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

+ Reply to Thread