Re: permissive vs. restrictive issue and solutions...

sdsat_private

On Fri, 1 Jun 2001, Howard Holm wrote:

> In summary, if you haven't already guessed, I'm finding the arguments
> for migrating all security logic into modules more compelling than
> those against.

Although I agree with the idea of migrating all of the security logic
into the modules in principle, I think it may be a mistake for us
to do so right now for the following reasons:

1) It is likely to be politically difficult to gain acceptance
from the Linux kernel developers for such pervasive and significant
changes to the Linux kernel.  It seems wiser to go for an incremental
approach - first gain acceptance for a set of new hook calls in the
kernel, leaving the existing base logic alone, and demonstrate the
value of the new hooks through example modules, and then subsequently
lobby for migrating the base logic into the hook functions.

2) The work factor for changing _all_ of the existing locations
where the base logic exists is quite substantial, does not directly
contribute to supporting _any_ of our security modules, and
could prevent us from making timely progress in this effort.

3) The potential for introducing subtle bugs by trying to migrate
all of the existing logic behind the hook interfaces seems high.
This is especially true since the right location for inserting
our hook calls often does not correspond with the locations of
existing logic, and our hook calls often need more information
than existing logic (e.g. the capable logic is merely based on
process state, and the capable calls often occur immediately on
entry to a system call, before kernel copies are made of
parameters that are needed by the hook).  An example of this
can be seen in the existing changes to the delete_module call,
where the hook call doesn't cover all of the same cases as
the original capable() check.

--
Stephen D. Smalley, NAI Labs
ssmalleyat_private

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