On Sun, Nov 18, 2018 at 9:43 AM Eric W. Biederman <[email protected]> wrote: > > Daniel Colascione <[email protected]> writes: > > > On Sun, Nov 18, 2018 at 9:13 AM, Andy Lutomirski <[email protected]> wrote: > >> On Sun, Nov 18, 2018 at 8:29 AM Daniel Colascione <[email protected]> > >> wrote: > >>> > >>> On Sun, Nov 18, 2018 at 8:17 AM, Andy Lutomirski <[email protected]> wrote: > >>> > On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione <[email protected]> > >>> > wrote: > >>> >> > >>> >> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski <[email protected]> > >>> >> wrote: > >>> >> > I fully agree that a more comprehensive, less expensive API for > >>> >> > managing processes would be nice. But I also think that this patch > >>> >> > (using the directory fd and ioctl) is better from a security > >>> >> > perspective than using a new file in /proc. > >>> >> > >>> >> That's an assertion, not an argument. And I'm not opposed to an > >>> >> operation on the directory FD, now that it's clear Linus has banned > >>> >> "write(2)-as-a-command" APIs. I just insist that we implement the API > >>> >> with a system call instead of a less-reliable ioctl due to the > >>> >> inherent namespace collision issues in ioctl command names. > >>> > > >>> > Linus banned it because of bugs iike the ones in the patch. > >>> > >>> Maybe: he didn't provide a reason. What's your point? > >> > >> My point is that an API that involves a file like /proc/PID/kill is > >> very tricky to get right. Here are some considerations: > > > > Moot. write(2) for this interface is off the table anyway. The right > > approach here is a system call that accepts a /proc/pid directory file > > descriptor, a signal number, and a signal information field (as in > > sigqueue(2)). > > If we did not have the permission check challenges and could perform > the permission checks in open, write(2) would be on the table. > Performing write(2) would only be concrend about data. > > Unfortunately we have setresuid and exec which make that infeasible > for the kill operations.
setresuid() should be irrelevant. If you had permission to kill a process and the process calls setresuid(), you should still have permission to kill it. For execve(), we could make execve() invalidate the fd. (See other email.)
