On Thu, Jul 2, 2020 at 5:16 PM Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > On Wed, Jul 01, 2020 at 08:49:06AM +0200, Adrian Reber wrote: > > From: Nicolas Viennot <Nicolas.Viennot@xxxxxxxxxxxx> > > > > Previously, the current process could only change the /proc/self/exe > > link with local CAP_SYS_ADMIN. > > This commit relaxes this restriction by permitting such change with > > CAP_CHECKPOINT_RESTORE, and the ability to use ptrace. > > > > With access to ptrace facilities, a process can do the following: fork a > > child, execve() the target executable, and have the child use ptrace() > > to replace the memory content of the current process. This technique > > makes it possible to masquerade an arbitrary program as any executable, > > even setuid ones. > > > > Signed-off-by: Nicolas Viennot <Nicolas.Viennot@xxxxxxxxxxxx> > > Signed-off-by: Adrian Reber <areber@xxxxxxxxxx> > > This is scary. But I believe it is safe. > > Reviewed-by: Serge Hallyn <serge@xxxxxxxxxx> > > I am a bit curious about the implications of the selinux patch. > IIUC you are using the permission of the tracing process to > execute the file without transition, so this is a way to work > around the policy which might prevent the tracee from doing so. > Given that SELinux wants to be MAC, I'm not *quite* sure that's > considered kosher. You also are skipping the PROCESS__PTRACE > to SECCLASS_PROCESS check which selinux_bprm_set_creds does later > on. Again I'm just not quite sure what's considered normal there > these days. > > Paul, do you have input there? I agree, the SELinux hook looks wrong. Building on what Christian said, this looks more like a ptrace operation than an exec operation. -- paul moore www.paul-moore.com
