Messages in this thread | | | Date | Thu, 25 Oct 2007 12:38:20 +0100 | Subject | Re: Linux Security *Module* Framework (Was: LSM conversion to static interface) | From | "Simon Arlott" <> |
| |
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/
| |