Re: [RFC 2/2] prctl: PR_SET_MM -- Introduce PR_SET_MM_MAP operation

[Kees Cook]

On Thu, Jul 24, 2014 at 6:48 AM, Andrew Vagin <avagin@xxxxxxxxxxxxx> 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

-- 
Kees Cook
Chrome OS Security
--
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/