From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Colascione Subject: Re: [PATCH] proc: allow killing processes via file descriptors Date: Sun, 18 Nov 2018 17:16:23 -0800 Message-ID: References: <20181118190504.ixglsqbn6mxkcdzu@yavin> <20181119000928.h2wp2rn2pnlfysp7@yavin> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: Aleksa Sarai Cc: Andy Lutomirski , Randy Dunlap , Christian Brauner , "Eric W. Biederman" , LKML , "Serge E. Hallyn" , Jann Horn , Andrew Morton , Oleg Nesterov , Al Viro , Linux FS Devel , Linux API , Tim Murray , Kees Cook , Jan Engelhardt List-Id: linux-api@vger.kernel.org On Sun, Nov 18, 2018 at 4:53 PM, Daniel Colascione wrote: >> Sure, I'd propose that ptrace_may_access() is what we should use for >> operation permission checks. > > The tricky part is that ptrace_may_access takes a struct task. We want > logic that's *like* ptrace_may_access, but that works posthumously. > It's especially tricky because there's an LSM hook that lets > __ptrace_may_access do arbitrary things. And we can't just run that > hook upon process death, since *after* a process dies, a process > holding an exithand FD (or whatever we call it) may pass that FD to > another process, and *that* process can read(2) from it. > > Another option is doing the exithand access check at open time. I > think that's probably fine, and it would make things a lot simpler. > But if we use this option, we should understand what we're doing, and > get some security-conscious people to think through the implications. A ptrace check is also probably too strict. Yama's ptrace_scope feature will block ptrace between unrelated processes within a single user context, but applying this restriction to exit code monitoring seems too severe to me.