Re: Time to remove LSM (was Re: [RESEND][RFC][PATCH 2/7]implementation of LSM hooks)

[Arjan van de Ven]

On Mon, 2006-04-24 at 10:54 +0200, Lars Marowsky-Bree wrote:
> > > 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.

yet exploring this space is worthwhile to a certain degree to find the
edges and see if there's a valid issue. Killing the discussion
prematurely makes no sense (but giving too much value to it doesn't make
too much sense either)

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

Now that the second user is laid bare, I do think it's a valid thing to
at least reevaluate the current state of LSM. So far it appears to not
really be the right interface for AppArmor, and it's also not really the
right interface for SELinux. And it has downsides in its design (the
function pointer tree is just a major source for sucky performance;
processors regardless of vendor don't like function pointer calls much).

So at minimum a debate about most the hooks is in order, as well as the
mechanism; I'm increasingly getting convinced the 'security_ops' thing
is misdesigned. I rather have a setup where the hooks at compiletime
resolve to the function of the LSM you've chosen (be it SELinux or
AppArmor) rather than the current solution. It's not like you
realistically can or want to provide both SELinux and AppArmor with the
same kernel anyway.. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/