netdev - Re: RFC: disablenetwork facility. (v4)

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