lkml.org 
[lkml]   [2007]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Linux Security *Module* Framework (Was: LSM conversion to static interface)
    From

    On Wed, October 24, 2007 22:02, David P. Quigley wrote:
    > Apparmor wants to lock down some application, it gives the application
    > access to a particular port, and the minimal set of privileges needed to
    > execute the application. Since Apparmor is "easy to use" (note the
    > quotes are to indicate they aren't my words not sarcasm) and SUSE comes
    > with a targeted policy the user isn't concerned with it. Now multiadm
    > comes along and an administrator wishes to grant extra rights to a user.
    > This is fine with multiadm alone since it is the main security module,
    > however we now have to compose this with AppArmor. So an administrator
    > runs into an error running his application. Is this because his user
    > isn't granted the proper escalated privileges? Is it because AppArmor
    > needs an extra rule to run the application? It could also be that our
    > third module has blocked the application because it determined that even
    > though multiadm specified that the user should have the elevated
    > privileges to run the application that user shouldn't be able to bind to
    > that port.
    >
    > There might be a better example to illustrate the problem however, this
    > simple example shows the interdependency of three seemingly simple
    > modules. Imagine what happens when people really let loose and implement
    > all sorts of crazy ideas and stack them on top of each other. Stacking
    > works in things such as file systems because we have a clearly defined
    > interface with fixed solid semantics. You could attempt to do that but
    > once you have modules that step on each others toes you have to figure
    > out a way to reconcile that. It seems to me that you're going to
    > introduce usability problems that are hard to deal with.

    I agree that it can cause problems, but it's up to the modules themselves
    to determine how to combine permissions with their immediate secondary
    module.

    Instead we now have a static LSM where combining features from one module
    means duplicating it in another - then when two modules contain most of
    the other's code, but perhaps vastly different configuration mechanisms,
    someone will propose removing one of the two...

    --
    Simon Arlott
    -
    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: 2007-10-25 13:41    [W:0.023 / U:1.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site