linux-kernel - Re: [CFT][PATCH] ptrace: Properly initialize ptracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 23 May 2017 07:40:58 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Takashi Iwai <tiwai@...e.de>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [CFT][PATCH] ptrace: Properly initialize ptracer_cred on fork

Takashi Iwai <tiwai@...e.de> writes:

> On Tue, 23 May 2017 07:47:32 +0200,
> Takashi Iwai wrote:
>> 
>> On Mon, 22 May 2017 23:04:48 +0200,
>> Eric W. Biederman wrote:
>> > 
>> > 
>> > When I introduced ptracer_cred I failed to consider the weirdness of
>> > fork where the task_struct copies the old value by default.  This
>> > winds up leaving ptracer_cred set even when a process forks and
>> > the child process does not wind up being ptraced.
>> > 
>> > Because ptracer_cred is not set on non-ptraced processes whose
>> > parents were ptraced this has broken the ability of the enlightenment
>> > window manager to start setuid children.
>> > 
>> > Fix this by properly initializing ptracer_cred in ptrace_init_task
>> > 
>> > This must be done with a little bit of care to preserve the current value
>> > of ptracer_cred when ptrace carries through fork.  Re-reading the
>> > ptracer_cred from the ptracing process at this point is inconsistent
>> > with how PT_PTRACE_CAP has been maintained all of these years.
>> > 
>> > Fixes: 64b875f7ac8a ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
>> > Signed-off-by: "Eric W. Biederman" <ebiederm@...ssion.com>
>> > ---
>> > 
>> > If I could get some folks to test and verify this fixes the
>> > enlightenment issue I would really appreciate it.
>> 
>> This seems giving a compile warning and it becomes error in the
>> following:
>> 
>> In file included from ./include/linux/mutex.h:13:0,
>>                  from ./include/linux/kernfs.h:13,
>>                  from ./include/linux/sysfs.h:15,
>>                  from ./include/linux/kobject.h:21,
>>                  from ./include/linux/device.h:17,
>>                  from drivers/gpu/drm/i915/gvt/kvmgt.c:32:
>> ./include/linux/ptrace.h: In function ‘ptrace_init_task’:
>> ./arch/x86/include/asm/current.h:17:17: error: passing argument 3 of ‘__ptrace_link’ discards ‘const’ qualifier from pointer target type [-Werror=discarded-qualifiers]
>>  #define current get_current()
>>                  ^
>> ./include/linux/ptrace.h:210:41: note: in expansion of macro ‘current’
>>    __ptrace_link(child, current->parent, current->ptracer_cred);
>>                                          ^~~~~~~
>> In file included from ./arch/x86/include/asm/stacktrace.h:10:0,
>>                  from ./arch/x86/include/asm/perf_event.h:246,
>>                  from ./include/linux/perf_event.h:24,
>>                  from ./arch/x86/include/asm/kvm_host.h:24,
>>                  from ./include/linux/kvm_host.h:37,
>>                  from drivers/gpu/drm/i915/gvt/kvmgt.c:41:
>> ./include/linux/ptrace.h:56:13: note: expected ‘struct cred *’ but argument is of type ‘const struct cred *’
>>  extern void __ptrace_link(struct task_struct *child,
>>              ^~~~~~~~~~~~~
>> cc1: all warnings being treated as errors
>
> Through a quick test on VM (fixed patch by adding const to
> __ptrace_link() argument), it seems working fine.

Thank you.  It seems when I fixed the const issue in my tree I forget
commit --amend so the fix didn't make it into the patch I sent out.

> Tested-by: Takashi Iwai <tiwai@...e.de>

Just to confirm.  You were able to reproduce the enlightenment failure
and this fixes it?

Eric