Re: Defense in depth: LSM *modules*, not a static interface

[Crispin Cowan]

Simon Arlott wrote:
> On Tue, October 30, 2007 07:14, Cliffe wrote:
>   
>> And while I acknowledge that many of these layers are currently buried
>> within the kernel (netfilter...) they are security layers which in many
>> cases would probably make sense as stackable security modules.
>>
>> Making the interface static forces mammoth solutions which then must
>> attempt to solve all of the above in one ls*m*. What happened to
>> dividing tasks into easy to manage chunks?
>>     
> Would it be possible to have Kconfig select which LSM should handle each
> area of security? Selecting LSM A would automatically disable LSM B and
> C since they both implement the same security functions, while LSM D
> would still be selectable since it implements something else. The default
> capabilities code would then turn off parts of itself that another LSM
> is handling.
>   
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.


> Alternatively the M in LSM can be restored and modules can be stacked.
> It should be possible for the primary LSM to check the security_ops of the
> secondary LSM(s) and complain if it considers there to be an incompatiblity.
>   
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/