Message-ID: <4B32F304.4040609@schaufler-ca.com>
Date:	Wed, 23 Dec 2009 20:50:12 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Michael Stone <michael@...top.org>
CC:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Andi Kleen <andi@...stfloor.org>, David Lang <david@...g.hm>,
	Oliver Hartkopp <socketcan@...tkopp.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Valdis Kletnieks <Valdis.Kletnieks@...edu>,
	Bryan Donlan <bdonlan@...il.com>,
	Evgeniy Polyakov <zbr@...emap.net>,
	"C. Scott Ananian" <cscott@...ott.net>,
	James Morris <jmorris@...ei.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Bernie Innocenti <bernie@...ewiz.org>,
	Mark Seaborn <mrs@...hic-beasts.com>,
	Randy Dunlap <randy.dunlap@...cle.com>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Casey Schaufler <casey@...aufler-ca.com>
Subject: Re: A basic question about the security_* hooks

Michael Stone wrote:
> Dear kernel folks,
>
> There are a variety of places where I'd like to be able to get the
> kernel to
> return EPERM more often [1]. Many of these places already have
> security hooks.

That should make it easy!

>
> Unfortunately, I don't feel that I can make effective use of these hooks
> because they seem to be "occupied" by the large mandatory access control
> frameworks.

The only reason that your use might not be effective is if
you want to integrate with one or more of those frameworks.
Go ahead and use the LSM for your own nefarious purposes, that
is what it is there for. The whole point of the LSM is that
no two projects could agree on the right approach for moving
security forward. Heavens to Betsy, none of the existing
LSMs have demonstrated themselves as the Way and the Light.

The current set of hooks have grown as needed, primarily driven
by the needs of SELinux, the largest of the Mandatory Access
Control frameworks. Most recently growth has matched the needs
of TOMOYO.

> I'm hoping that you can tell me why this state of affairs persists.

Serious security models, including Type Enforcement, Bell
and LaPadula, Biba, Clark/Willson, Simple Separation, and
Green Light Ice remain the interest of a very small fragment
of the lunatic fringe of computer system deployments. So
long as the mechanism that supports this small but vocal
community is adequate to the task and easy for the rest
of the Linux universe to ignore everyone is more or less
content.

>
> More specifically, now that LSMs are statically linked, why is it good
> for the
> security hooks to call into a single monolithic "security_ops" struct
> instead
> of cheaper and simpler alternatives?

By all means, suggest an implementation ...

>
> In particular, what would be worse about a kernel in which each
> security hook
> contained nothing but conditionally-compiled function calls to the
> appropriate
> "real" implementation functions with early-exit jumps on non-zero
> return codes?

The question is not would it be worse, the question has to be
whether it would be better. In particular, would it be better
for the people who want nothing whatever to do with an LSM,
which remains by far the larger set of people.

>
> Thanks,
>
> Michael
>
> [1]: Two examples include my recent network-privileges patches and Eric
> Biederman's suggestions on how to make unprivileged
> unshare(CLONE_NEWNET) safe.
> I have little doubt that I'd think of more if I thought that the
> security hooks
> were accessible to me.

You're arguing for stacking a set of small security modules. This
is a direction that has gotten slammed pretty hard in the past but
that crops up every time someone like you comes along with a
module that serves a specific purpose. Mostly the objections have
come from people who will tell you that something else already
does what you're trying to do, and that all you have to do is take
on the entirety of their monolithic approach and you'll be happy.

I'm behind you 100%. Use the LSM. Your module is exactly why we have
the blessed thing. Once we get a collection of otherwise unrelated
LSMs the need for a stacker will be sufficiently evident that we'll
be able to get one done properly.


And just in case it matters, I understand that this is an unpopular
position. I am an advocate of progress, not necessarily my own
peculiar notions of computer security. I believe that we should keep
trying new things for the simple reason that in the twenty plus
years that I've been working on the problem no one has demonstrated
a solution that addresses more than a fraction of the whole. Lots of
great ideas have gotten discarded because they didn't fit into an
MLS system, SELinux, the Linux file system semantics, or the teeny
tiny little minds that control the IETF.



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

Powered by blists - more mailing lists