From: "Serge E. Hallyn" <serge@hallyn.com>
To: Michael Stone <michael@laptop.org>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
linux-kernel@vger.kernel.org,
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>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
Samir Bellabes <sam@synack.fr>,
Casey Schaufler <casey@schaufler-ca.com>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: A basic question about the security_* hooks
Date: Sat, 26 Dec 2009 21:16:31 -0600 [thread overview]
Message-ID: <20091227031631.GA17629@hallyn.com> (raw)
In-Reply-To: <20091226195043.GA1945@heat>
Quoting Michael Stone (michael@laptop.org):
> Now, given this argument, what do you actually think about systems that, like
> your work, enable stacking but which do so "less automatically", e.g. by
> hand-writing the implementations of the security_*() hooks like so:
>
> int security_socket_create(int family, int type, int protocol, int
> kern) {
> int ret = 0;
>
> #ifdef CONFIG_SECURITY_SELINUX
> ret = selinux_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_TOMOYO
> ret = tomoyo_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_SMACK
> ret = smack_security_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> #ifdef CONFIG_SECURITY_PRCTL_NETWORK
> ret = prctl_network_socket_create(family, type, protocol, kern);
> if(ret)
> goto out;
> #endif
>
> out:
> return ret;
> }
>
> This way, the behavior of the system is as predictable as possible, we can
> statically check for known unsafe configurations, manual tweaking of the order
> in which functionality is composed is possible, and security is fully
> "pay-as-you-go".
>
> Where is the flaw in this approach?
Well, according to Mimi's email this is essentially what was
decided upon for IMA. So I think workable guidelines would
be that anything which can't possibly be expected to interfere
with other LSMs can be added like that.
More generally, the flaw in the approach is that the hooks for
several permutations of LSMs might interfere with each other.
So for instance the cap_inode_setxattr() hook should always
be called if selinux is not enabled, but should not be called
for security.selinux namespace xattrs if selinux is enabled.
Rather than try to capture all the permutations in one
security_socket_create() hook, we would want to just arrange
some stacking orders, and have the 'parent' hooks call the
'child' hooks. That is precisely what I was suggesting in my
previous posts.
Oh, you'll also want to take into consideration whether
the LSM is actively loaded, since I can compile a kernel
with smack, SELinux, TOMOYO, and your system, but only
load smack. So just #ifdef isn't enough. Just a note.
Anyway, your LSM may be specific enough to qualify for the
IMA treatment (like you suggest). So no harm in trying :)
But I wouldn't try to overly generalize the stacking, as I'd
fear it risks becoming a drag on the acceptence of the rest of
your patch.
-serge
next prev parent reply other threads:[~2009-12-27 3:04 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-24 2:29 A basic question about the security_* hooks Michael Stone
2009-12-24 4:50 ` 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 [this message]
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=20091227031631.GA17629@hallyn.com \
--to=serge@hallyn.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=andi@firstfloor.org \
--cc=bdonlan@gmail.com \
--cc=bernie@codewiz.org \
--cc=casey@schaufler-ca.com \
--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=michael@laptop.org \
--cc=mrs@mythic-beasts.com \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=randy.dunlap@oracle.com \
--cc=sam@synack.fr \
--cc=serue@us.ibm.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