[lkml]   [2014]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation
On Thu, Jul 24, 2014 at 6:48 AM, Andrew Vagin <> wrote:
> On Tue, Jul 22, 2014 at 01:07:51PM -0700, Kees Cook wrote:
>> > - @exe_fd is referred from /proc/$pid/exe and when generating
>> > coredump. We uses prctl_set_mm_exe_file_locked helper to update
>> > this member, so exe-file link modification remains one-shot
>> > action.
>> Controlling exe_fd without privileges may turn out to be dangerous. At
>> least things like tomoyo examine it for making policy decisions (see
>> tomoyo_manager()).
> We don't want to reduce security. How can we get a process with a
> target exe link, which executes our code?
> We can execute the target file and attach to it with ptrace. ptrace
> allows to inject and execute any code.
> So if we are sure that we are able to do a previous scenario, we can
> safely change exe-link, can't we?
> prctl already has a check of permissions to execute the target file.
> If we execute a file. What can prevent us to attach to the process with ptrace?
> The file can have a suid bit, so after executing it we may lose ability
> to attach to it. To check that we can check that uid and gid is zero
> in a current userns (local root).
> What else do we need to check?

Yeah, I think all the checks are sufficient, but I (and Julien) are
still trying to think about side-effects.

It would be nice if these checks (like the rlimit checks) were merged
into some common helper. That way if something changes in the exec
path, it won't go missed in the c/r path.


Kees Cook
Chrome OS Security

 \ /
  Last update: 2014-07-24 21:21    [W:0.053 / U:0.660 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site