Valdis.Kletnieks@private wrote:
>On Tue, 30 Nov 2004 14:08:27 CST, "Serge E. Hallyn" said:
>
>
>>I don't think that calling of capable from modules is a problem, because it
>>is not actually called from any module's capable itself. It's used to
>>check for specific privileges, and if any stacked LSM does not want to
>>grant that privilege, then any action depending on that privilege should
>>probably be refused.
>>
>>
>
>Hmm.. so whatever is running the hooks calls LSM A, which decides to check
>whether CAP_FOO is asserted. As a result, it ends up calling LSM B's code -
>quite possibly getting us into a situation where:
>
>1) LSM A denies the request because LSM B's code said "no".
>2) even though LSM B's code didn't see a problem with granting the request,
>because it never even bothers to check for CAP_FOO in the hook for that request.
>
>
Right: stacking arbitrary security policies is intractable :)
You *cannot* create a general solution to this, because in the general
case, security modules can completely disagree on an operation, and
there is no way for a stacking module to resolve that without breaking
at least one of the modules.
In a purely restrictive model, you can generalize the simple case of
"operation allowed if all modules allow it", but I don't believe you can
automate "A allows it if B is loaded/allows it/denies it/votes Republican".
The Capable calls are problematic for this stacking, because they are
not purely restrictive. IMHO they are also important, because throughout
LSM development, when ever anyone whined about how the LSM hooks being
all restrictive were too limiting, we pointed them at Capable hooks.
Since I don't actually believe that stacking is all that useful in the
general case, I would actually rather have the permissive Capable hooks
than a powerful stacking composition capability. So what I would like to
see is:
* keep the stacking mechanism as simple as possible, aiming at the
"allow if all modules allow" composition policy and not much else
* if there is a conflict between Capable and stacker, choose Capable
Crispin
--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com
This archive was generated by hypermail 2.1.3 : Tue Nov 30 2004 - 14:39:07 PST