On Mon, 05 Nov 2001 14:16:33 PST, Greg KH said:
> On Mon, Nov 05, 2001 at 12:58:43PM -0800, Casey Schaufler wrote:
> > I understand the "foot in the door" approach. Watch your toes,
> > and be ready to spend a long time waiting for something
> > useful to get in. I'm disappointed, and now have to figure
> > out how to address the real issues this position raises.
>
> That's a pretty unfair statement. Your use of "useful" is relative.
> The current LSM patch is very useful to a number of existing security
> projects: SELinux, DTE, vserver, OpenWall, SubDomain, NetDomain, and
> others.
On the other hand, it's interesting that the current patch is "useful"
to a number of projects that all operate in the context of the limited
model provided (restrictive-only hooks), but which has been conclusively
shown to NOT be useful for anything that wants authoritative hooks.
I have to agree with Casey - this puts SGI in a *very* bad spot, because
they *want* to ship audit and ACL support, but doing so would force them
to explain why LSM wasn't sufficient.
And let's face it. If we step back a bit and look at it, this *does*
look silly:
"Well, we could use Linux - the new LSM stuff provides security exits"
"Would we be able to do ACLs?" "Erm, no. They decided against supporting that."
"Would we be able to generate an audit trail?" "Erm, no. That got dropped out."
"Then what's it good for?" "Erm... SOME stuff uses it"
"Why isn't the rest of the stuff in there?" "They thought a real solution
wouldn't be accepted"
"So what you're saying is that the Linux world isn't serious about security?"
Now let's go back and look at Crispin's 3 concerns:
1. It is more invasive.
Yes. But not by much - and *EITHER* authoritative or restrictive hooks
are invasive. Personally, considering the fact that this is an attempt
to bolt security onto a project after the fact (usually a bad idea), it's
surprising that it's as non-invasive as it is.
/dev/random is pretty invasive too - it's got its grubby hooks into the
disk drivers to gather entropy and all that. Should it have been made
a lot less invasive by only gathering entropy from one or two places?
Or should it be invasive enough to get the job done?
The base LSM patch (lsm-2001_10_24-2.4.13.patch.gz) is 9,356 lines long.
Richard Offer's update of authoritative hooks subtracts *33* lines, and
adds *68* lines. Once you allow for a *lot* of add/sub pairs being movement
of a line of code, that's less than one percent bigger than the base LSM
patch.
It's surprising how 10,000 lines of patches are acceptably invasive, but
another 40 lines of code is too much.
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.
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?
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.
--
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
This archive was generated by hypermail 2b30 : Mon Nov 05 2001 - 14:22:39 PST