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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
