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] [day] [month] [year] [list]
Message-Id: <20160225.114343.1977846344387184355.davem@davemloft.net>
Date:	Thu, 25 Feb 2016 11:43:43 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	nicolas.dichtel@...nd.com
Cc:	ebiederm@...ssion.com, khlebnikov@...dex-team.ru,
	netdev@...r.kernel.org, containers@...ts.linux-foundation.org,
	vvs@...tuozzo.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ipv4: in new netns initialize sysctls in
 net.ipv4.conf.* with defaults

From: Nicolas Dichtel <nicolas.dichtel@...nd.com>
Date: Thu, 25 Feb 2016 15:20:48 +0100

> Le 24/02/2016 23:05, Eric W. Biederman a écrit :
> [snip]
>> In the general case the current behavior is random and not something
>> applications can count on, and we would do well to fix it so it is
>> less
>> random.  In particular consider the case of an application in a
>> non-initial network namespace creating a new network namespace.  It is
>> not even possible to predict what values they will get for sysctls
>> today.
> +1

But there is a counter argument to this.

The admin set up the initial namespace so that any namespace
instantiated by a user (even non-initial namespaces) starts with a
specific set of sysctl values.  So the admin "knows", he set it up
intentionally this way, and it's a valid model.

This behavior is anything but random.  Rather, it is very predictable
and controllable.

Do you really want to find out who you're going to break out there with
so many installations in the world right now?

I do not.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ