linux-kernel - Re: A basic question about the security

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 24 Dec 2009 18:14:22 -0600
From:	"Serge E. Hallyn" <serue@...ibm.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>
Subject: Re: A basic question about the security_* hooks

Quoting Michael Stone (michael@...top.org):
> 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?

The problem is that composing any two security policies can quickly have
subtle, unforeseen, but dangerous effects.  That's why so far we have
stuck with the status quo where only one LSM is 'active', but that LSM
can manually call hooks from other LSMs.

So with your module, I'd recommend following the route of the capabilities
LSM.  You can provide an optional stand-alone LSM which only hooks your
functions.  Then smack, for instance, can call the functions in your LSM
from within its own hooks, or it can simply explicitly assign its hooks to
your functions in smack_ops.  Selinux can do the same thing, although I
suspect they would more likely implement their own functions for your newly
hooked sites.

A distro can then compile a kernel with all LSMs compiled in, and switch
behavior by using "security=selinux" vs. "security=prctl_network_lsm"

-serge
--
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/