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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
