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