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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 26 Dec 2009 21:16:31 -0600
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Michael Stone <michael@...top.org>
Cc:	"Serge E. Hallyn" <serue@...ibm.com>, 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>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
	Samir Bellabes <sam@...ack.fr>,
	Casey Schaufler <casey@...aufler-ca.com>,
	Pavel Machek <pavel@....cz>
Subject: Re: A basic question about the security_* hooks

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