Re: [PATCH] mm: larger stack guard gap, between vmas
From: Andy Lutomirski
Date: Wed Jul 05 2017 - 20:32:34 EST
On Wed, Jul 5, 2017 at 4:55 PM, Linus Torvalds
> On Wed, Jul 5, 2017 at 4:50 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote:
>> As part of that should we put restrictions on the environment of
>> set*id exec too?
> I'm not seeing what sane limits you could use.
> I think the concept of "reset as much of the environment to sane
> things when running suid binaries" is a good concepr.
> But we simply don't have any sane values to reset things to.
I wonder if we could pull some "sane" values out of our arses and have
it work just fine.
It's worth noting that a lot of the rlimits don't meaningfully
restrict the use of any particular resource, so we could plausibly
drop requirements to have privilege to increase them if we really
cared to. I don't see why we'd make such a change, but it means that,
if we reset on set*id and therefore poke a hole that allows a program
to do "sudo -u $me whatever" and thereby reset limits, it's not so
bad. A tiny survey:
RLIMIT_AS: not a systemwide resource at all.
RLIMIT_CORE: more or less just a policy of what you do when you crash.
I don't see how you could do much damage here.
RLIMIT_CPU: unless you're not allowed to fork(), this doesn't restrict
RLIMIT_FSIZE: maybe? but I can see this being quite dangerous across set*id
RLIMIT_MEMLOCK: this one matters, but it also seems nearly worthless
RLIMIT_MSGQUEUE: privilege matters here
RLIMIT_NICE: maybe? anyone who actually cares would use cgroups instead
RLIMIT_NOFILE: great for exploits. Only sort of useful for resource management
RLIMIT_NPROC: privilege matters here
RLIMIT_RTTIME: privilege kind of matters. Also dangerous for exploits
(a bit) since it lets you kill your children at controlled times.
RLIMIT_SIGPENDING: not sure
*** means that this is a half-arsed resource control. It's half-arsed
because this stuff doesn't cover mmap(2), which seems to me like it
defeats the purpose. This stuff feels like a throwback to the