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: Tue, 29 Dec 2009 03:06:16 -0800 From: ebiederm@...ssion.com (Eric W. Biederman) To: Michael Stone <michael@...top.org> Cc: "Serge E. Hallyn" <serue@...ibm.com>, linux-kernel@...r.kernel.org, netdev@...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>, 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>, Al Viro <viro@...IV.linux.org.uk> Subject: Re: RFC: disablenetwork facility. (v4) Michael Stone <michael@...top.org> writes: > Serge, > > I think that Pavel's point, at its strongest and most general, could be > rephrased as: > > "Adding *any* interesting isolation facility to the kernel breaks backwards > compatibility for *some* program [in a way that violates security goals]." *some* privileged program. > The reason is the one that I identified in my previous note: > > "The purpose of isolation facilities is to create membranes inside which > grievous security faults are converted into availability faults." > > The question then is simply: > > "How do we want to deal with the compatibility-breaking changes created by > introducing new isolation facilities?" You have a very peculiar taxonomy of the suggestions, that fails to capture the concerns. I strongly recommend working out a way to disable setuid exec. Ideally we would use capabilities to achieve this. Serge can we have a capability that unprivelged processes normally have an can drop without privelege? I can see one of two possible reasons you are avoiding the suggestion to disable setuid root. - You have a use for setuid root executables in your contained environment. If you do what is that use? - Disabling suid root executables is an indirect path to your goal. The problem with the disable_network semantics you want is that they allow you to perform a denial of service attack on privileged users. An unprivileged DOS attack is unsuitable for a general purpose feature in a general purpose kernel. Your sysctl, your boot option, your Kconfig option all fail to be viable options for the same reason. Your facility is only valid in an audited userspace. Disabling setuid-exec especially to a subset of processes is valid in an unaudited userspace as it does not allow propagating the DOS to privileged processes. Eric -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists