On Wed, Oct 31, 2018 at 07:33:06PM +0000, Daniel Colascione wrote: > On Wed, Oct 31, 2018 at 6:17 PM, Tycho Andersen <ty...@tycho.ws> wrote: > > On Wed, Oct 31, 2018 at 06:00:49PM +0000, Daniel Colascione wrote: > >> On Wed, Oct 31, 2018 at 5:54 PM, Tycho Andersen <ty...@tycho.ws> wrote: > >> > Why not just use an ioctl() like Jann suggested instead of this big > >> > security check? Then we avoid the whole setuid writer thing entirely, > >> > >> Don't you think a system call would be better than a new ioctl? > > > > We already have a kill() system call :) > > kill(2) is useless this purpose: it accepts a numeric PID, but we'd > need it to accept a process file descriptor instead. It's true that > the existing kill(1) binary might be the vehicle for using a > hypothetical new system call, but that's a separate matter. > > >> With either an ioctl or a new system call, though, the shell would > >> need a helper program to use the facility, whereas with the existing > >> approach, the shell can use the new facility without any additional > >> binaries. > > > > ...and a binary to use it! > > > > The nice thing about an ioctl is that it avoids this class of attacks > > entirely. > > Let's stop talking about adding an ioctl. Ioctls have problems with > namespacing of the request argument; it's not safe, in general, to > issue an ioctl against a file descriptor of an unknown type.
So don't lose track of the fd type. I'm not sure I see this as a big problem. > You don't know how that FD will interpret your request code. The two > good options before us are a write(2) interface and a new system > call. I think both are defensible. But I don't see a good reason to > consider adding an ioctl instead of a system call. https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1729911.html https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1729921.html maybe? :) > All of this is moot if the new comprehensive process interface that > comes out of LPC ends up being better anyway. +1, I think a way to do all of this sort of thing would be nice. > > either. Using this from the shell is still racy, because if I do > > something like: > > > > echo 9 > /proc/$pid/kill > > > > There's exactly the same race that there is with kill, that $pid might > > be something else. > > > Of course I could do some magic with bind mounts or > > my pwd or something to keep it alive, but I can already do that today > > with kill. > > You can't do it today with kill. The idea that keeping a open file > descriptor to a /proc/pid or a file within it prevents PID reuse is > widespread, but incorrect. Good to know :) Tycho
