public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Michael Stone <michael@laptop.org>
To: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org,
	"Andi Kleen" <andi@firstfloor.org>, "David Lang" <david@lang.hm>,
	"Oliver Hartkopp" <socketcan@hartkopp.net>,
	"Alan Cox" <alan@lxorguk.ukuu.org.uk>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Valdis Kletnieks" <Valdis.Kletnieks@vt.edu>,
	"Bryan Donlan" <bdonlan@gmail.com>,
	"Evgeniy Polyakov" <zbr@ioremap.net>,
	"C. Scott Ananian" <cscott@cscott.net>,
	"James Morris" <jmorris@namei.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	"Bernie Innocenti" <bernie@codewiz.org>,
	"Mark Seaborn" <mrs@mythic-beasts.com>,
	"Randy Dunlap" <randy.dunlap@oracle.com>,
	"Américo Wang" <xiyou.wangcong@gmail.com>,
	"Michael Stone" <michael@laptop.org>
Subject: A basic question about the security_* hooks
Date: Wed, 23 Dec 2009 21:29:02 -0500	[thread overview]
Message-ID: <20091224022902.GA24234@heat> (raw)

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.

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.

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

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?

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?

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.

             reply	other threads:[~2009-12-24  2:27 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-24  2:29 Michael Stone [this message]
2009-12-24  4:50 ` A basic question about the security_* hooks Casey Schaufler
2009-12-24 12:53   ` Eric W. Biederman
2009-12-24 21:55     ` Tetsuo Handa
2009-12-25  0:05     ` Serge E. Hallyn
2009-12-31 17:50       ` David P. Quigley
2010-01-04  2:12     ` Paul Moore
2009-12-24  7:36 ` Evgeniy Polyakov
2009-12-24 18:57   ` Samir Bellabes
2009-12-25  0:14 ` Serge E. Hallyn
2009-12-25  1:11   ` Michael Stone
2009-12-25  5:50     ` Serge E. Hallyn
2009-12-26 19:50       ` Michael Stone
2009-12-27  3:16         ` Serge E. Hallyn
2009-12-27  4:02           ` Tetsuo Handa
2009-12-27 10:56             ` Valdis.Kletnieks
2009-12-27 14:54               ` Serge E. Hallyn
2009-12-27 20:28               ` David Wagner
2009-12-28  2:08                 ` Valdis.Kletnieks
2009-12-28 11:51               ` Tetsuo Handa
2009-12-28 14:45                 ` Valdis.Kletnieks
2009-12-28 14:51                 ` Valdis.Kletnieks
2009-12-29 13:01                   ` Label based MAC + Name based MAC (was Re: A basic question about the security_* hooks) Tetsuo Handa
2010-01-02 13:56                 ` A basic question about the security_* hooks Pavel Machek
2009-12-28 15:24         ` Kyle Moffett
2009-12-29  1:43           ` Casey Schaufler
2009-12-29 19:02             ` Kyle Moffett
2009-12-30 19:49               ` Casey Schaufler
2009-12-27  0:33       ` Mimi Zohar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091224022902.GA24234@heat \
    --to=michael@laptop.org \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andi@firstfloor.org \
    --cc=bdonlan@gmail.com \
    --cc=bernie@codewiz.org \
    --cc=cscott@cscott.net \
    --cc=david@lang.hm \
    --cc=ebiederm@xmission.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=mrs@mythic-beasts.com \
    --cc=randy.dunlap@oracle.com \
    --cc=socketcan@hartkopp.net \
    --cc=xiyou.wangcong@gmail.com \
    --cc=zbr@ioremap.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox