It appears to me that the deck is stacked. No matter what is asked of Casey & friends to do to get authoritative hooks in, the bar is moved each time they pass a hurdle. First, the argument was that the complexity was much, much more than restrictive hooks. 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. 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. Now, it's "show us an access control mechanism that requires no Linux patches (given LSM is in the kernel)". As the below remarks demonstrate, you -could- come up with such a case, although they are not planning on it. I would take bets that if they actually did the work to produce a module with no patches needed, someone would say "show us that it could generate sales", and then, no doubt, "show us that the product makes a profit", or some such nonsense. Yes, some here never wanted authoritative hooks, and at each stage in the long process, tried (and try) to kill it. 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? I hope not. I'm quite annoyed with the treatment given to Casey and Richard over the past few months with regard to this issue and the moving targets they have to reach. Is it possible for all sides to operate in good faith here and resolve this fairly? --steve kramer -----Original Message----- From: Casey Schaufler Cc: linux-security-moduleat_private Sent: 10/30/01 4:57 PM Subject: Re: Authoritative hooks updated to 2.4.13 Stephen Smalley wrote: > > On Tue, 30 Oct 2001, Stephen Smalley wrote: > > > Do you actually have a POSIX ACL security module that uses LSM and does > > not require any other kernel patches? > > Sorry, that wasn't clear. That question should be: Do you actually have > a POSIX ACL security module that uses LSM + the authoritative hooks patch > and does not require any other kernel patches? Hell, I doubt you could find a kernel that boots that doesn't require any patches! Seriously, we're talking about a set of works-in-progress: LSM, ACLs, Extended Attributes, XFS, and so on. We could make ACLs work under authoritative LSM without any other patches, but doing so might require some additional hooks. Of course, there's no incentive to do so under the current conditions. Plus, there's always the potential for things like the directory default ACL functionality that LSM might reasonably want to defer to Phase II. So, no, I wouldn't say there would be no other patches required. I would say that does not make a usable LSM worthless. Nor would I say that invalidates the arguement that LSM ought to support this. I would say that even with this, an LSM which does not provide useful service for a facility as important as POSIX ACLs is pretty pointless. _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Tue Oct 30 2001 - 15:44:41 PST