Paul Davis <[EMAIL PROTECTED]> wrote: > > >And as I mentioned a few times, the authors have neither the inclination > >nor the ability to do that, because they are not kernel hackers. The > >realtime LSM was written by users (not developers) of the kernel, to > >solve a specific real world problem. No one ever claimed it was the > >correct solution from the kernel POV. > > i would just like to add that its very disappointing that the LSM, > having been included in the kernel (apparently very much against > Christoph's and others' advice) turns out to be so useless. from > outside lkml, LSM appeared to be a mechanism to allow > non-kernel-developers to create new security policies (perhaps even > mechanisms) without trying to tackle the entire kernel. instead, we > are now getting a fix which, while it solves the same problem, has > required substantive analysis of its effect on the overall kernel, and > will require continued vigilance to ensure that it doesn't now or > later cause unintended side effects. LSM appeared to be the "right" > way to do this in terms of modularity - it is disappointing to find it > has so little support (close to zero to judge from this debate) on > LKML despite being present in the kernel. >
That, plus the fact that inherited capabilities could also be used here, except they don't work right. That's a nice, simple and long-standing kernel feature which I think we should have fixed up before piling in more security features. But I've said that often enough. If nobody has a sufficient need for fixed-up-caps to actually put work into it, nothing happens. And it's a lot of work, because this is a scary feature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/