Re: Authoritative Hooks

crispinat_private

Casey Schaufler wrote:

>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.
>
Sorry.  Really.

>>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 my perspective that, after 30 years of trying, failure to 
compromise security for ease of use has cost the security community the 
sale. As a result, secure systems, to a first approximation, do not 
exist in the market place. LSM's primary goal is not to provide the best 
security possible, but rather to make some pretty good security as 
widely available as possible. To do that, it must be as close as 
possible to free (in every sense of the word) or it will get rejected at 
critical junctures by folks who do not hold security as their dominant 
concern.  "Make it acceptable, and as secure as possible" rather than 
the other way around.

>>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.
>
Hey, we agree on something :-)

> We believe this is poor
>practice from both political and technical directions.
>
The converse practice has been SOP in the security community forever, 
resulting in poor sales.

>>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 Linux is stingy with breaking compatibility at the API level, it 
is explicitly permitted to break ABI compatibility in the module 
interface. I do not expect backward-compatibility arguments against 
improvements in LSM's interface.

>>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.
>
If we can get the timing right, I would encourage that:

   1. We get restrictive LSM accepted.
   2. SGI proposes ACLs (not audit :-) to Linux, pointing out that LSM
      is insufficient in some respects.
   3. LSM gets upgraded to add the stuff that ACLs need.

Cost/benefit is the crux of the opposition to Authoritative.  Greg et al 
see the cost as substantial, much more so than Casey. Casey et al see 
the benefit as substantial, but until the modules that need the features 
show up, that argument is hard to make convincingly to others.

> There
>are significant arguements that the restrictive LSM is worse for
>our purposes than no LSM at all.
>
IFF one believes, as Casey says above, that the LSM ABI is frozen once 
initially accepted.  I do not believe that, as it is not consistent with 
Linux LKM history.

>We are forced to consider weather to endorse with reservations, withhold position, or actively oppose adoption of the LSM.
>
Guess which one I'm hoping for :-)

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc. http://wirex.com
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html

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