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
| ||
|
Message-ID: <CALCETrVh8Xu3VJzseWEJZ+ryy5WANyJg+j4=hFaVFebzSu_TgQ@mail.gmail.com> Date: Wed, 23 Feb 2022 11:44:51 -0800 From: Andy Lutomirski <luto@...nel.org> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: linux-api@...r.kernel.org, Etienne Dechamps <etienne@...champs.fr>, Alexey Gladkov <legion@...nel.org>, Kees Cook <keescook@...omium.org>, Shuah Khan <shuah@...nel.org>, Christian Brauner <brauner@...nel.org>, Solar Designer <solar@...nwall.com>, Ran Xiaokai <ran.xiaokai@....com.cn>, linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org, Linux Containers <containers@...ts.linux-foundation.org>, Michal Koutný <mkoutny@...e.com>, security@...nel.org, Neil Brown <neilb@....unsw.edu.au>, NeilBrown <neilb@...e.de>, "Serge E. Hallyn" <serge@...lyn.com>, Jann Horn <jannh@...gle.com> Subject: Re: How should rlimits, suid exec, and capabilities interact? On Wed, Feb 23, 2022 at 10:00 AM Eric W. Biederman <ebiederm@...ssion.com> wrote: > > > [CC'd the security list because I really don't know who the right people > are to drag into this discussion] > > While looking at some issues that have cropped up with making it so > that RLIMIT_NPROC cannot be escaped by creating a user namespace I have > stumbled upon a very old issue of how rlimits and suid exec interact > poorly. Once upon a time, these resource limits were effectively the only way to control memory consumption and consumption of historically limited resources like processes. (The scheduler used to have serious issues with too many processes -- this is not so true any more. And without cgroups, too many processes could use too much CPU collectively.) This all worked pretty poorly. Now we have cgroups, fancy memory accounting, etc. So I'm wondering if NPROC is even useful anymore. I don't have a brilliant idea of how to deprecate it, but I think it wouldn't be entirely nuts to take it much less seriously and maybe even eventually get rid of it. I doubt there is much existing userspace that would break if a previously failing fork() started succeeding. --Andy]
Powered by blists - more mailing lists