Re: Security through Permissiveness: A Zen Riddle? (Crispin Cowan)

chrisat_private

* Matt Block (mattat_private) wrote:
> 
> I was under the impression that the capabilities code was seen as
> somewhat monolithic and a pain to deal with, and precisely the kind of
> thing that the LSM hooks would allow to be modularized and separated.
> Which is to say that by allowing no permissive hooks, the LSM is
> dictating the use of capabilities, or a different security policy.  And,
> again, IIRC it is a project goal that the hooks oughtn't to dictate
> policy (indeed, that the point of the project was to separate security
> policy).

yes, we started out looking at replacing all of the calls to capable,
and realized it was an unrealistic goal in the short term.  don't be
confused.  just because the function call is "capable" does not mean
it _is_ by definition POSIX.1e capabilities.  we use that hook to
leverage all the code in the kernel that pre-dates this project.
these hooks become lsm permissive hooks at the granularity of the linux
implementation of capabilities (note:  there are many capabilities in
the linux implementation that are not specified in the POSIX.1e draft).
so consider that an lsm could utilize the permissive hooks (courtesy of
the original capable() call) to implement a security policy that does
not look like POSIX.1e capabilities.

> If someone supplies a broken module, they can cause your kernel to not
> boot.  Or compromise permissions on your system.  Or silently truncate
> your logs.  That remains true whether the kernel incorporates LSM hooks
> or not, so the default fail safe principle is at least difficult,
> perhaps impossible to apply to the kernel.  In other words, that
> principle is and will be violated no matter what decision is made wrt
> the placement of hooks.  As such, it seems to me that the LSM hooks
> should support a permissive model so that the principle can at lesat be
> applied aggressively at the level of security policy, which should be
> outside the demesne of the hooks themselves.

i agree that a broken module is a broken module is a broken module.  yes
it's all kernel code.  i think crispin is referring to the simple
assurance property being...even if i really screw up my own access
control logic i am not making the kernel any less secure than it was.
and the only way i can really screw things up (besides the fact that i
have access to all of kernel memory) is in the capable call.  this isn't
failsafe meaning if i dereference a NULL pointer i will failsafe, this
is more like i won't give away the farm with one bad logic error.
(kinda hand wavey i know, it's friday evening ;-)
> 
> I'm betraying a certain naivete as regards the kernel political process,
> I'm sure, but I would like to see as eventual goals of this project the
> ability for an _administrator_ (not a module creator or kernel hacker)
> to implement policy on his system by integrating (potentially several)
> modules, each one capturing some portion of the intended policy; the
> ability for an administrator to use security modules from (potentially)
> many different sources _at the same time_; the ability for an
> administrator to use particular modules at different points (read: the
> ability to gracefully load and unload modules without effecting other
> modules).  These goals point to an expanded effort along the lines of
> JMJs chaining, but also to an abundance of hooks admitting of
> permissiveness as well as restriction.

this is a fine goal.  we are trying to focus on mainline kernel
acceptance.  linus has already voiced a strong opinion against module
chaining.  we provide a mechanism to support it that essentially
offloads all of the hard parts of module compostion to the module
developer so that it is not inherent in the kernel code.

cheers,
-chris

_______________________________________________
linux-security-module mailing list
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module