RE: Authoritative hooks updated to 2.4.13

sdsat_private

On Tue, 30 Oct 2001, KRAMER,STEVEN (HP-USA,ex1) wrote:

> First, the argument was that the complexity was much,
> much more than restrictive hooks.

The authoritative hooks patch is more invasive and it does increase the
likelihood that a security module may accidentally open a vulnerability
in the base logic.  It also introduces a greater risk of error in the
kernel itself, as shown most recently in the sys_setpriority handling.
These are simple facts - take a close look at the patch if you don't
believe me.  On the positive side, the authoritative hooks patch makes
LSM more expressive.  So there are various tradeoffs, not to be lightly
dismissed.

> The argument last summer was that, if SGI
> goes off and writes the diffs to turn the restrictive hooks into
> authoritative hooks, it would be considered in earnest.  They go off and
> return with diffs that most would agree aren't so that much more.

Actually, they were asked to examine my authoritative hooks patch and
see what additional changes they needed.  They took my authoritative hooks
patch and have maintained it, but have essentially dropped any other
requested changes.  And although the size in bytes and number of lines
added/removed may not be so different, there is a definite difference in
invasiveness if you actually look at the patches.

> Now, the
> argument has changed.  It's been changed to "show us an access control need
> is there", and SGI immediately returns with "POSIX ACLs".
> POSIX ACLs are certainly a good example, once agreed upon as the defacto ACL
> standard by a number of major companies.

I think that this has always been a requirement for LSM.  We can't expect
the kernel developers to accept LSM without examples of real open source
projects that use it.  We don't currently have any such examples of
security modules that use authoritative hooks.

> Now, it's "show us an access
> control mechanism that requires no Linux patches (given LSM is in the
> kernel)".

Ok, so maybe this isn't fair.

> However, there was consensus in
> the summer to let SGI come up with the auth patch and, if it didn't
> introduce a large degree of complexity, to let it go into BK.  What ever
> happened to that?  Are we now retreating to the earlier disagreement before
> the compromise was made?

At least two key contributors to LSM weren't present at that BOF - Greg
K-H and James Morris, both of whom have actually gotten code into the
mainstream kernel.  And we know that Greg has never agreed to
authoritative hooks.

--
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