On Sat, Jul 22, 2023 at 12:40:46PM -0700, Philip Guenther wrote: > On Sat, 22 Jul 2023, p...@delphinusdns.org wrote: > > >Synopsis: delaying ptrace(2)'ing a process about to change credentials > > >Category: kernel > > >Environment: > > System : OpenBSD 7.3 > > Details : OpenBSD 7.3 (GENERIC.MP) #2080: Sat Mar 25 14:20:25 MDT > > 2023 > > > > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > > > Architecture: OpenBSD.arm64 > > Machine : arm64 > > >Description: > > In many scenarios it's possible to attach to a root owned process > > with ptrace(2) after it changes credentials to non-root. > > Is this something you've managed to implement? > > As is, I'm not seeing how this will happen: > * initially, the target process has ruid==0 > * during the set*uid syscall, it holds the kernel lock across the update > of ps_ucred and setting PS_SUGID in its ps_flags > * the process doing ptrace(PT_ATTACH) holds the kernel lock across the > check you quoted, so it can't see target_ruid==my_ruid without also > seeing PS_SUGID set > > > What am I missing? > > > Philip Guenther
No I haven't implemented this. Thanks for clarifying that the PS_SUGID flag is set here. I had thought that this is a flag that is associated with setuid/setgid binaries (ie. 04000/02000 mode). Is it possible for the attacking process to deliver a SIGABRT to the target process without doing the ptrace() though? It's a different thing though. It also is highly unlikely due to the random pids, so I'll let it rest. Thanks for clarifying Philip! Best Regards, -peter -- Over thirty years experience on Unix-like Operating Systems starting with QNX.
