aboutsummaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorVasiliy Kulikov <segoon@openwall.com>2011-08-08 11:02:04 -0400
committerLinus Torvalds <torvalds@linux-foundation.org>2011-08-11 14:24:42 -0400
commit72fa59970f8698023045ab0713d66f3f4f96945c (patch)
treeed9a5eaf8212270d464c6d4396ae5a568352a997 /fs
parent1d229d54dbc26971142f61c3d271a68db236d178 (diff)
move RLIMIT_NPROC check from set_user() to do_execve_common()
The patch http://lkml.org/lkml/2003/7/13/226 introduced an RLIMIT_NPROC check in set_user() to check for NPROC exceeding via setuid() and similar functions. Before the check there was a possibility to greatly exceed the allowed number of processes by an unprivileged user if the program relied on rlimit only. But the check created new security threat: many poorly written programs simply don't check setuid() return code and believe it cannot fail if executed with root privileges. So, the check is removed in this patch because of too often privilege escalations related to buggy programs. The NPROC can still be enforced in the common code flow of daemons spawning user processes. Most of daemons do fork()+setuid()+execve(). The check introduced in execve() (1) enforces the same limit as in setuid() and (2) doesn't create similar security issues. Neil Brown suggested to track what specific process has exceeded the limit by setting PF_NPROC_EXCEEDED process flag. With the change only this process would fail on execve(), and other processes' execve() behaviour is not changed. Solar Designer suggested to re-check whether NPROC limit is still exceeded at the moment of execve(). If the process was sleeping for days between set*uid() and execve(), and the NPROC counter step down under the limit, the defered execve() failure because NPROC limit was exceeded days ago would be unexpected. If the limit is not exceeded anymore, we clear the flag on successful calls to execve() and fork(). The flag is also cleared on successful calls to set_user() as the limit was exceeded for the previous user, not the current one. Similar check was introduced in -ow patches (without the process flag). v3 - clear PF_NPROC_EXCEEDED on successful calls to set_user(). Reviewed-by: James Morris <jmorris@namei.org> Signed-off-by: Vasiliy Kulikov <segoon@openwall.com> Acked-by: NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'fs')
-rw-r--r--fs/exec.c17
1 files changed, 17 insertions, 0 deletions
diff --git a/fs/exec.c b/fs/exec.c
index da80612a35f4..25dcbe5fc356 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1459,6 +1459,23 @@ static int do_execve_common(const char *filename,
1459 struct files_struct *displaced; 1459 struct files_struct *displaced;
1460 bool clear_in_exec; 1460 bool clear_in_exec;
1461 int retval; 1461 int retval;
1462 const struct cred *cred = current_cred();
1463
1464 /*
1465 * We move the actual failure in case of RLIMIT_NPROC excess from
1466 * set*uid() to execve() because too many poorly written programs
1467 * don't check setuid() return code. Here we additionally recheck
1468 * whether NPROC limit is still exceeded.
1469 */
1470 if ((current->flags & PF_NPROC_EXCEEDED) &&
1471 atomic_read(&cred->user->processes) > rlimit(RLIMIT_NPROC)) {
1472 retval = -EAGAIN;
1473 goto out_ret;
1474 }
1475
1476 /* We're below the limit (still or again), so we don't want to make
1477 * further execve() calls fail. */
1478 current->flags &= ~PF_NPROC_EXCEEDED;
1462 1479
1463 retval = unshare_files(&displaced); 1480 retval = unshare_files(&displaced);
1464 if (retval) 1481 if (retval)