From: Leonard den Ottolander <hidden> Date: 2017-03-08 18:18:31
On Wed, 2017-03-08 at 12:54 -0500, Carlos O'Donell wrote:
The most demanding application I've ever seen when playing with this is the
compiler because it has to pass some very large strings from the driver
to a subprocess. So much so that we have `@file` to use intermediate file
storage to workaround kernel limits on various operating systems.
So a value that would satisfy glibc would suffice. Any problem with that
limit of 4096 arguments? The size of each individual argument is still
the old limit of 128KiB.
By the way, my kernel build example seems to already catch your
scenario. Kernel build uses a compiler.
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.
Regards,
Leonard.
--
mount -t life -o ro /dev/dna /genetic/research
From: Joseph Myers <hidden> Date: 2017-03-08 20:47:33
On Wed, 8 Mar 2017, Leonard den Ottolander wrote:
If you don't feel the limit of 4096 arguments is sufficient please
provide us with an example where that limit is insufficient.
mv * /some/where/
(in a directory with many files).
Linking thousands of .o files into a large program or putting them in a .a
file in a single command.
Constructing a make command line with thousands of -o options to mark
files as considered to be old (a real case where I ran into the old 128k
limit when it was there).
There are of course workarounds for these - but "the number of files in
the source + build trees of a very large project" seems a better way of
judging limits than 4096.
--
Joseph S. Myers
joseph-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org
From: Carlos O'Donell <hidden> Date: 2017-03-08 21:05:38
On 03/08/2017 01:18 PM, Leonard den Ottolander wrote:
On Wed, 2017-03-08 at 12:54 -0500, Carlos O'Donell wrote:
quoted
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.