Re: Authoritative Hooks

caseyat_private

Crispin Cowan wrote:
> 
> I'm afraid that the authoritative hooks patch is not going to be
> accepted into LSM prior to its initial submission to the kernel
> developers.

Well, foo.

> After careful consideration, none of the LSM committers are
> comfortable with accepting this patch at this time.
> As has been noted previously, the authoritative hooks patch raises at
> least the following concerns:
> 
>    1. It is more invasive.
>    2. It increases the likelihood that modules can accidentally
>       undermine the base logic.
>    3. It increases the likelihood that the LSM patch will introduce an
>       error into the base kernel.

It remains our opinion, based on a dozen years experiance
with similar intergartion issues, that these arguements are
insignificant in the face of the extreme limitations of
the restrictive hook scheme.

> It is our belief that these changes do not belong in the initial version
> of LSM (especially given our limited charter and original goals), and
> should be proposed as incremental refinements after LSM has been
> initially accepted. These changes pose a risk to the initial acceptance
> of LSM, which could jeopardize the existing open source security modules
> that have no need of these changes.

It is our position that the LSM group has decided to compromise
the product in order to make the sale. We believe this is poor
practice from both political and technical directions.

> The arguments here are similar to those against moving all of the kernel
> access control logic from the base kernel into the security modules in
> the initial LSM. While this may be a worthy long term goal, it is not a
> practical first step for LSM, and after careful consideration, it seems
> that neither are authoritative hooks. We must walk before we can run.

It is our view that the limitations of the proposed scheme,
and the issues of backward compatability are likely to prevent
positive motion in the future. While we can accept the current
LSM as a step, we do not see it as a step in the right direction.

> We appreciate SGI's participation in LSM and hope that they will
> continue to participate despite this setback. It is our belief that the
> current LSM will provide a meaningful improvement in the security
> infrastructure of the Linux kernel, and that there is plenty of room for
> future expansion of LSM in subsequent phases. We look forward to
> continuing to work with SGI as long as they are willing to do so.

This is a major question for us. Should we propose Audit and ACL
patches, with explainations of why we couldn't use LSM, there is
very real concern that the weakness of LSM will come out. There
are significant arguements that the restrictive LSM is worse for
our purposes than no LSM at all. We are forced to consider weather
to endorse with reservations, withhold position, or actively oppose
adoption of the LSM.

Thank y'all for your participation, and the rousing good fun
of working in a community environment. I haven't seen such
technical bruhaha since POSIX.

-- 

Casey Schaufler				Manager, Trust Technology, SGI
caseyat_private				voice: 650.933.1634
casey_pat_private			Pager: 888.220.0607

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