Re: [PATCH 0/3] extend get/setrlimit to support setting rlimitsexternal to a process (v7)
From: Ingo Molnar
Date: Mon Nov 02 2009 - 13:52:03 EST
* Neil Horman <nhorman@xxxxxxxxxxxxx> wrote:
> > Have you ensured that no rlimit gets propagated during task init
> > into some other value - under the previously correct assumption that
> > rlimits dont change asynchronously under the feet of tasks?
> I've looked, and the only place that I see the rlim array getting
> copied is via copy_signal when we're in the clone path. The entire
> rlim array is copied from old task_struct to new task_struct under the
> protection of the current->group_leader task lock, which I also hold
> when updating via sys_setprlimit, so I think we're safe in this case.
I mean - do we set up any data structure based on a particular rlimit,
that can get out of sync with the rlimit being updated?
A prominent example would be the stack limit - we base address layout
decisions on it. Check arch/x86/mm/mmap.c. RLIM_INFINITY has a special
meaning plus we also set mmap_base() based on the rlim.
Also, there appears to be almost no security checks in the new syscall!
We look up a PID but that's it - this code will allow unprivileged users
to lower various rlimits of system daemons - as if it were their own
limit. That's a rather big security hole.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/