Re: Authoritative hooks updated to 2.4.13

caseyat_private

Stephen Smalley wrote:
> 
> 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

Don't give me any of that crap. The differance has been
demonstrated to be neglegable. If we came in with authoritative
hooks that were two lines and three K smaller you'd stiil say that.

> and it does increase the
> likelihood that a security module may accidentally open a vulnerability
> in the base logic.

Oh my gosh! you mean, a loadable security module might
actually change the security enforcement? Oh No!
And here it was, I thought that was what we were out
to accomplish.

> It also introduces a greater risk of error in the
> kernel itself, as shown most recently in the sys_setpriority handling.

Red Herring.

> These are simple facts - take a close look at the patch if you don't
> believe me.

These are simply arguments against development by the
inexperianced. I would not make such arguements. Not
in a Linux context.

> On the positive side, the authoritative hooks patch makes
> LSM more expressive.  So there are various tradeoffs, not to be lightly
> dismissed.

But @#$%^&* it, they have been.

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

Yes, and thank you.

> but have essentially dropped any other
> requested changes.

Bullshit. Take that back. I fart in your general direction.
Your mother smelt of elderberries. 

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

What are you using for an invas-o-meter? Mine doesn't
detect any such definite difference.

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

ACLs can't use LSM because of restrictive hooks. ACLs can't
be used to argue that LSM needs authoritative hooks because
ACLs doesn't use LSM. Thus, the fact that something can't use
LSM is an arguement that LSM should stay the way it is.

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

That's right. To date, we've gone along with this anyway.
I asked Richard and Lachlan what it would take to meet the
current set of "requirements" and they told me not to
bother, we were just going to get told off anyway.

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

Yes, and many of the key contributors were there. You were there.
We have never agreed to restrictive hooks, and we were there,
and have been here. Never mind us, we just plan to use the LSM.
Excuse me, would like to use LSM. Probably won't be able to.
Will most likely have to request our own security enforcement
patches because LSM won't be useful.

-- 

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