On Thu, October 25, 2007 02:42, Casey Schaufler wrote:
quoted text
>
> I agree that security code does need to provide security. What we
> need to get away from is the automatic attacks that are based on 20th
> century computer system assumptions. Things like "name based access
> control is rediculous", and "a module can't be any good if it doesn't
> deal with all objects", or "the granularity isn't fine enough". Look
> at TOMOYO. It's chuck full of good ideas. Why spend so much energy
> badgering them about not dealing with sockets? How about helping the
> AppArmor crew come up with acceptable implementations rather than
> whinging about the evils of hard links? And maybe, just maybe, we can
> get away from the inevitable claim that you could do that with a few
> minutes work in SELinux policy, but only if you're a security
> professional of course.

What may be even more relevant are those concepts that couldn't be done
in SELinux, and how proposals that come from the theory of alternative
access controll models (like object capability modeling) are dismissed
by the aparently largely MLS/MAC oriented people on the list.

In a wider contect than just this list, it apears to me that MLS and
Obj Caps advocates simply dismiss the alternative models as broken or as
irrelevant at best. In my view this attitude is very much pressent on
the MLS list.

It might in the light of this attitude even be a viable option to just
simply spin off 3 (or more) sets of LSM module sets, and maybe even put
some ifdefs in the base code depending on the chosen access controll model,
if for some reason the 'model' warants some major patch.

To me it would look like a good concept if LSM/Linux would try to support
all exisiting formal models of access controll, but without the need to
support all implementation alternatives for these models. That is, if a
module 'requires' a patch but the underlaying formal model does not, than
it would seem reasonable that the module be fixed. If however the 'model'
seems to require the patch, it may be perfectly reasonable for this patch
to be implemented, if need be with an ifdef for the used model.

Thus IMHO it may be a good idea to instead of a maintainer for LSM
modules as proposed, alternatively a maintainer for each formal model
may be more appropriate. This also would require module builders to first
think about what formal model they are actualy using, thus resulting in
cleaner module design.



Rob

-
unsubscribe notice
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/