Simon Arlott wrote:I get what you mean, but the problem is that there is little consensus on what "area" means. Rather the opposite, it could easily be the case that different modules have such a different view of the world that you cannot easily mechanically determine whether they can stack. Some categories that occur to me: * Restrictive vs. Permissive: o LSM is mostly restrictive, but the POSIX.1e Capabilities hooks are permissive. o Some modules like MultiADM and File Capabilities are deliberately permissive, while others like AppArmor and SMACK are purely restrictive. o In any kind of stacking scheme, it would be important to load the permissive modules first, followed by the restrictive modules. o This becomes problematic as soon as you have a module that is both permissive and restrictive. o Note: AppArmor is both permissive and restrictive because it incorporates the Capabilities code rather than trying to stack with it. With a good clean stacker, AA might be able to become purely restrictive. * Access control vs. Intrusion prevention: o An Access control policy is one that specifies what a confined subject can access. o An Intrusion prevention engine specifies classes of things that may never happen, e.g. the Openwall hard and symbolic link restrictions. o An intrusion prevention mechanism might be a blanket effect that prevents the Bad Thing from happening for all processes, or it might be policy driven, and only prevent the Bad Thing for explicitly confined processes, or explicitly allow the Bad Thing for permitted processes. o Access control and Intrusion Prevention modules are naturally complementary, making stacking very attractive. o Note: SELinux already incorporates some intrusion prevention features, and AppArmor plans to incorporate such features. With a good clean stacker, AA might be able to instead use stacking. That is what I advocate. Restore the modular feature immediately, this static interface is lots of cost (mostly opportunity cost) and very little benefit (mostly defense against contrived FUD threats). Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work -
| Stephen Smalley | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Robin Holt | Re: Linux 2.6.26-rc1 |
git: | |
| David Fenyes | sigsetmask()? (LINUX) |
| Theodore Ts'o | Re: SVGA-alphanum. modes |
| Rob Coleman | S3 |
| Ian Kluft | 2nd CFV and VOTE ACK: comp.os.linux reorganization |
