--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> If the argument is that we should favor the
> traditional over the good,
> then I think you've lost your case.
Ah, but you see, the fact that something
is traditional does not necessarily make
it bad! Call me an old fuddy duddy, but I
actually prefer MAC+Cap to TE. I
understand that many people prefer TE and
that's OK with me.
> Besides, Type Enforcement has quite
> a bit of history behind it, coming from
> at least the LOCK work in the
> early 80s, with the underlying origins traceable to
> the Lampson ('71)
> and Linden ('76) papers, so let's compare
> traditions, shall we?
If you like, although we really should have
a couple beers and an audience for that.
> > Restictive LSM modules ought to be completely
> > stackable if they are in fact strictly
> > restrictive.
>
> Strictly restrictive relative to base Linux DAC, but
> not necessarily to
> one another. See the issues noted in the
> next-to-last para of:
> http://www.nsa.gov/selinux/papers/module/x341.html
Yup, the shared blob is the trick to stacking.
> Also, getting the stacker module correct even for
> the "simple"
> combination of capabilities and SELinux was
> surprisingly difficult - see
> the lsm list archives for the history of that.
> Serge made a valiant
> effort of fixing each issue as I discovered them,
> but the history shows
> that it isn't as trivial as one might think.
It's true that the Capabilities stacking in
SELinux points out some important issues.
Given the mixture of privilege models its
tough to see a better approach.
Casey Schaufler
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
