Re: [PATCH 2.6.13-rc6 1/2] New Syscall: get rlimits of any process

From: Kyle Moffett
Date: Tue Aug 16 2005 - 12:56:22 EST


On Aug 16, 2005, at 13:34:34, Wieland Gmeiner wrote:
On Sat, 2005-08-13 at 15:11 -0700, Greg KH wrote:
On Fri, Aug 12, 2005 at 07:48:22PM +0200, Wieland Gmeiner wrote:

@@ -294,3 +294,4 @@ ENTRY(sys_call_table)
.long sys_inotify_init
.long sys_inotify_add_watch
.long sys_inotify_rm_watch
+ .long sys_getprlimit


Please follow the proper kernel coding style when writing new kernel
code...

Hm, Documentation/CodingStyle suggests using descriptive names, so
something like getrlimit(...)/getrlimit_per_process(pid_t pid, ...)
would be more appropriate?

I think he was commenting more on the code indentation and braces placement
than any naming issue. There was also a good guide to kernel whitespace
posted to the LKML a week or so ago, please check the archives and review
that as well.

I have one small comment on something you stated in your original mail:
Otherwise some checking on the validity of the given pid is
done and if the given process is found access is granted if

- the calling process holds the CAP_SYS_RESOURCE capability or
- the calling process uid equals the uid of the process whose rlimit
is being read or
- the calling process uid equals the suid of the process whose rlimit
is being read or
- the calling process euid equals the uid of the process whose rlimit
is being read or
- the calling process euid equals the suid of the process whose
rlimit is being read

I suggest that you revise this list to the following:
If the calling process can ptrace the target process, then allow rlimits to be
read and written such that the hard limits may not be raised unless one of the
two processes possesses the CAP_SYS_RESOURCE capability

ptrace implies the ability to execute arbitrary code in the given process, which
means that even without this new function the calling process theoretically
could obtain and set rlimits for that process anyways, subject to its own
CAP_SYS_RESOURCE capability. Such a situation would guarantee that there are
no new security holes, and would limit the number of inter-process access rules
which kernel developers need to understand. I believe some simple Googling and
grepping through the kernel code should reveal the necessary ptrace- related
process checks.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to make it so
simple that there are obviously no deficiencies. And the other way is to make
it so complicated that there are no obvious deficiencies. The first method is
far more difficult.
-- C.A.R. Hoare


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