On 03/08/2017 01:18 PM, Leonard den Ottolander wrote: > On Wed, 2017-03-08 at 12:54 -0500, Carlos O'Donell wrote: >> In glibc we limit setuid applications, for example sanitizing their >> environment where it would cause problems or alter behaviour in >> unintended ways. >> >> Can we avoid imposing a limit on all applications? > > Not imposing a limit - btw, 0x7FFFFFFF *is* a limit albeit a ridiculous > and dangerously large limit - is a bad idea, because it allows the > aforementioned "heap-spraying" which is a serious attack vector. > > Note that 128KiB * 4096 arguments still adds up to 512MiB!!! > > If you don't feel the limit of 4096 arguments is sufficient please > provide us with an example where that limit is insufficient. (a) Justification. A good design should not unduly limit what users can do without a good justification. It is my opinion that it is not enough data to say that a kernel build is sufficient to justify a limit that will affect all applications. Minimally I'd expect you to run with such a kernel patch through an entire distro build cycle to see if anything else breaks. For example reaching out to the Fedora or SUSE teams to test the patch in Rawhide or Tumbleweed. What if 4096 is too much? Why not lower? You could try using systemtap or dtrace and running a distro start to finish and auditing the mean values you see (see (c) for a discussion on ensuring the userspace tooling remains correct after this change). (b) Attack vector. The privilege escalation in your example is caused by a fault in a setuid application. Can we impose stricter limits on setuid binaries instead of on all binaries? In glibc for example we do not allow certain environment variables to impact the behaviour of setuid binaries e.g. MALLOC_PERTURB_ env var is ignored in secure mode for setuid binaries (which might be used for similar heap-spraying). Can the kernel similarly enforce a different MAX_ARG_STRINGS for setuid? (c) What limit is appropriate? No limit is appropriate. Users should be able to use all of their system resources to accomplish whatever task they need to get done. Yes, portable applications have limits e.g. ARG_MAX, sysconf(_SC_ARG_MAX), xargs --show-limits, getconf ARG_MAX etc. We should make sure that any limit we set does not conflict with current implementations and standards conformance. Yes, limits should be balanced against security issues, and for setuid binaries I agree, but you propose a blanket limit, which is why I'm asking the question again: Can we impose stricter limits on setuid binaries instead of on all binaries? -- Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
