Messages in this thread | | | Date | Mon, 24 Apr 2006 10:54:56 +0200 | From | Lars Marowsky-Bree <> | Subject | Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7] implementation of LSM hooks) |
| |
On 2006-04-24T10:37:17, Arjan van de Ven <arjan@infradead.org> wrote:
> > Security models can be compromised by root or by dumb accomplices. Film > > at eleven. > well this security model wants to partition root, more or less. So to > some degree looking at it makes sense; just not so much in the given > example ;)
True.
> > Seriously, this is not helpful. Could we instead focus on the > > technical argument wrt the kernel patches? > I disagree with your stance here; trying to poke holes in the > mechanism IS useful and important. In addition to looking at the > kernel patches.
I agree, sort-of. Yet, I'd argue that the holes tried to poke here rely on the admin being sloppish not with regular operation, but _while configuring the security policy_. The only way to protect against that is to shoot the admin on sight.
Which might not be a bad idea, looking at the stats of the human error still being the most dangerous detail in any equation, yet it may be considered impractical.
> I understand your employer wants this merged asap, but that's no reason > to try to stop discussions that try to poke holes in the security model.
I resent that remark. At the same level I could argue that some other people in this discussion do have a professional interest in getting it _not_ merged. (And LSM ripped out _now_ before it gets a chance to address the comments made so far.) I'd rather not go there.
But while we're there, just really briefly, it is important to point out that while Novell/SUSE obviously _does_ have a corporate interest, it is not required for this to be "ASAP", and I trust that Crispin, Tony et al will work to incorporate all feedback received. I don't think we're in any rush, and even if LSM _is_ ripped out, that just means that the patch series will be augmented with a further patch [01/xx] "Reinstate LSM hooks w/additional provisions to address code cleanliness."
Going back to the technical side of things, I'd be more happy if the holes poked were something you could reasonably expect to be able to protect against.
Sincerely, Lars Marowsky-Brée
-- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge"
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |