Re: [PATCH 2.6.13-rc6 2/2] New Syscall: set rlimits of any process(update)

From: Stephen Smalley
Date: Thu Aug 18 2005 - 10:52:40 EST


On Thu, 2005-08-18 at 03:02 +0200, Wieland Gmeiner wrote:
> diff -uprN -X linux-2.6.13-rc6-vanilla/Documentation/dontdiff linux-2.6.13-rc6-getprlimit/security/selinux/hooks.c linux-2.6.13-rc6-setprlimit/security/selinux/hooks.c
> --- linux-2.6.13-rc6-getprlimit/security/selinux/hooks.c 2005-08-17 03:11:33.000000000 +0200
> +++ linux-2.6.13-rc6-setprlimit/security/selinux/hooks.c 2005-08-18 01:28:11.000000000 +0200
> @@ -2717,11 +2721,22 @@ static int selinux_task_setrlimit(unsign
> later be used as a safe reset point for the soft limit
> upon context transitions. See selinux_bprm_apply_creds. */
> if (old_rlim->rlim_max != new_rlim->rlim_max)
> - return task_has_perm(current, current, PROCESS__SETRLIMIT);
> + return task_has_perm(current, task, PROCESS__SETRLIMIT);
>
> return 0;
> }

This isn't sufficient for mandatory access control over setprlimit. As
long as the setrlimit operation could only be performed by the process
on itself, we were only concerned with controlling attempts to modify
the hard limit (not the soft limit), as that is being used as a safe
reset point for the soft limit upon security context transitions. But
for the case of setprlimit where the target process may differ, we need
to be able to control setting of any limit, soft or hard, in order to
control the ability of a process in one security context to modify the
state of a process in a different security context. Further, we would
need a parallel check on the getprlimit side, to control the ability of
a process in one security context to observe the state of a process in a
different security context.

--
Stephen Smalley
National Security Agency

-
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/