[rsbac] Remove LSM support from RSBAC 1.2.3-pre? Issues and musings.

[Klaus Holler]

Hi Amon,

I fully agree with you, especially Issue #3, #4 and #7 have much weight.
Issue #3: having a strong kernel-version dependency would suck, apart from 
the coding structure issues.
Issue #4/#7: the chaining concept used by LSM is IMHO bad, I dislike that the 
"weakest link in the chain" then determines the overall strength, without 
doubt the current concept of RSBAC is cleaner/safer - if one decision module 
fails, others still work...

All in all, I think you are on the right track ;-)
Regards, 
Klaus

On Monday, 13 October 2003 16:37, Amon Ott wrote:
> Issue #3 (low level internal data structures):
> LSM hooks export (expose) kernel internal data structures as parameters,
> from which all LSM modules have to extract their data. This is extremely
> dangerous, because a simple bug (like = instead of ==) can destabilize the
> whole system.
>
> Additionally, kernel internal data structures tend to be changed quite
> frequently between releases - with every new kernel version, one has to
> check whether the items are used correctly and if the correct locks are
> held. All this leads to a mess of #ifdefs for the kernel version, instead
> of the IMHO very important independency of kernel versions.
>
> Issue #4 (stacking):
> The LSM design is not able to support more than one single decision module
> registration. Instead, a system of secondary registrations ("stacking")
> has been introduced, which forms a call chain though all modules, until
> all have been called. Each module is responsible to forward the decision
> requests of all(!) hooks to its secondary module, and to combine its own
> and the secondary result to a return value.
>
> With the stacking system, each registered decision module holds all others
> along the chain in its mercy. I am not willing to accept such a dependency
> on other modules. Furthermore, the need to supply forwarding for all hooks
> makes all code more LSM version dependent and unnecessarily complicates
> the decision code.
>
> Issue #6 (no guaranteed decision call):
> With RSBAC, every registered decision function is guaranteed to be called
> for every decision, unless an internal error occurs (return value
> UNDEFINED). This is important for logging and, specially, for notification
> and state update.
>
> Those LSM modules I had a closer look at only forward requests, if they
> themselves allowed access. And, again, this is purely a decision of the
> module up in the chain. If it for some reason does not call its
> secondaries, too bad.
>

-- 
Klaus Holler <gmx.at after kho4l@>