Re: Authoritative Hooks

gregat_private

On Mon, Nov 05, 2001 at 05:21:34PM -0500, Valdis.Kletnieksat_private wrote:
> 
> "So what you're saying is that the Linux world isn't serious about security?"

Audit, and ACLs do not make up all of "security" :)

No, what the LSM group decided was to not support audit or ACLs right
now (and I haven't seen an ACL patch yet, to really verify this.)  What
they did decided to do is support the most minimal security patch they
could at first cut, which happens to support quite a number of different
security models.

> It's surprising how 10,000 lines of patches are acceptably invasive, but
> another 40 lines of code is too much.

The fact that 4 lines of patch causes a syscall to totally change it's
logic model is quite invasive.  The number of lines don't really matter.
In fact, the majority of lines of code in the patch is documentation,
followed by empty hooks, as the attached diffstat of the 2.4.13 lsm
patch shows.

>    2. It increases the likelihood that modules can accidentally
>       undermine the base logic.
> 
> Compare that to the likelyhood that a solution that is half-LSM and half patch
> will screw the base logic.

Huh?  If you want to have your own patch, you can do whatever you want
and mess up the base logic.  That's up to you.  I don't understand your
argument here.

>    3. It increases the likelihood that the LSM patch will introduce an
>       error into the base kernel.
> 
> Kernel errors will happen.  See the 2.4.11 kernel for an example.  There's
> been LOTS of code that got added to the kernel that wasn't quite ready
> the first time around - that's what the 2.3 and 2.5 series are *for*.
> 
> And how *DID* Arcangeli's VM get dropped into 2.4.10?  That's a *HELL* of
> a lot more invasive than anything we're writing.  Added in the middle of
> a 2.4 series, to boot.  We're collectively a damn sight lucky that *THAT*
> not-at-all-invasive change didn't introduce any errors into the kernel,
> aren't we?

The VM changes are not our concern.  They were done by people with a
_huge_ history of good solid kernel modifications.  The LSM team (as a
whole) has _no_ history of good kernel modifications.  The way to earn
that kind of trust is to contribute small, good, clean, and easily
provable as such, patches.  Only over time can you earn that kind of
trust.  We need to earn that trust.  Submitting huge patches that
radically change the base logic of the kernel does not help in achieving
that goal.

> But *NO*.  We need to worry about upsetting people with large patches in
> the 2.5 stream, even if they're only 25% bigger and make it a lot more
> usable for a lot more projects.

"A lot" so far == 2.  And no one has really proven the second one (ACLs).
How many projects work with the current patch?  A bunch.  How many will
work if we don't get any LSM patch in?  None :)

thanks,

greg k-h