From: Daniel Colascione <firstname.lastname@example.org> To: Andy Lutomirski <email@example.com> Cc: Randy Dunlap <firstname.lastname@example.org>, Christian Brauner <email@example.com>, "Eric W. Biederman" <firstname.lastname@example.org>, LKML <email@example.com>, "Serge E. Hallyn" <firstname.lastname@example.org>, Jann Horn <email@example.com>, Andrew Morton <firstname.lastname@example.org>, Oleg Nesterov <email@example.com>, Aleksa Sarai <firstname.lastname@example.org>, Al Viro <email@example.com>, Linux FS Devel <firstname.lastname@example.org>, Linux API <email@example.com>, Tim Murray <firstname.lastname@example.org>, Kees Cook <email@example.com>, Jan Engelhardt <firstname.lastname@example.org> Subject: Re: [PATCH] proc: allow killing processes via file descriptors Date: Sun, 18 Nov 2018 09:24:36 -0800 [thread overview] Message-ID: <CAKOZuesCKo4GH9fdum2EUFLrtTWam3aizcDQUn3-vCYg4T1P8w@mail.gmail.com> (raw) In-Reply-To: <CALCETrVg71XBv-gMOtL-m0Dd0HNz8_oXOUDSWin5LeViAL0UYA@mail.gmail.com> On Sun, Nov 18, 2018 at 9:09 AM, Andy Lutomirski <email@example.com> wrote: > On Sun, Nov 18, 2018 at 8:49 AM Daniel Colascione <firstname.lastname@example.org> wrote: >> >> On Sun, Nov 18, 2018 at 8:33 AM, Randy Dunlap <email@example.com> wrote: >> > On 11/18/18 8:17 AM, Andy Lutomirski wrote: >> >> On Sun, Nov 18, 2018 at 7:53 AM Daniel Colascione <firstname.lastname@example.org> wrote: >> >>> >> >>> On Sun, Nov 18, 2018 at 7:38 AM, Andy Lutomirski <email@example.com> 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. >> >> >> >>> >> >>>> I have an old patch to make proc directory fds pollable: >> >>>> >> >>>> https://lore.kernel.org/patchwork/patch/345098/ >> >>>> >> >>>> That patch plus the one in this thread might make a nice addition to >> >>>> the kernel even if we expect something much better to come along >> >>>> later. >> >>> >> >>> I've always commented on that patch. You never addressed my technical >> >>> objections. Why are you bringing up this patch again as if that >> >>> discussion had never happened? To review, that patch has various race >> >>> conditions >> >> >> >> I don't think I ever saw that review. >> >> >> >>> and even if it were technically correct, it'd be an abuse >> >>> of directory objects (in what other circumstance do we poll >> >>> directories?) and not logically generalizable to a model in which we >> >>> expose process exit status via the exit-monitoring API. >> >> >> >> I agree it's weird. It might be better to have /proc/PID/exit_status >> >> and make *that* pollable. >> >> >> > >> > If there is a new exit_status file, it could even be more than >> > 8 bits of exit status: >> > >> > See https://lore.kernel.org/lkml/alpine.LSU.firstname.lastname@example.org/T/#u >> > and http://austingroupbugs.net/view.php?id=594#c1317 >> >> First of all, as I discussed in , we need to first figure out *who* >> should have access to the process exit information. FreeBSD appears to >> make it public without disaster, and if we make exit status public, a >> lot of problems just disappear. > > I kind of want to go in the other direction of making a lot of process > information (especially cmdline) less publicly accessible. Okay. That has nothing to do with exit status. Please address the points related to the API we're discussing and that I raised in the other thread. Assuming we don't broaden exit status readability (which would make a lot of things simpler), the exit notification mechanism must work like this: if you can see a process in /proc, you should be able to wait on it. If you learn that process's exit status through some other means --- e.g., you're the process's parent, you can ptrace the process, you have CAP_WHATEVER_IT_IS_ --- then you should be able to learn the fate of the process. Otherwise you just be able to learn that the process exited. > Windows has an easy time of it because Windows has an easier time of it because it doesn't use an ad-hoc ambient authority permission model. In Windows, if you can open a handle to do something, that handle lets you do the thing. Period. There's none of this "well, I opened this process FD, but since I opened it, the process called setuid, so now I can't get its exit status" nonsense. Privilege elevation is always accomplished via a separate call to CreateProcessWithToken, which creates a *new* process with the elevated privileges. An existing process can't suddenly and magically become this special thing that you can't inspect, but that has the same PID and identity as this other process that you used to be able to inspect. The model is just better, because permission is baked into the HANDLE. Now, that ship has sailed. We're stuck with setreuid and exec. But let's be clear about what's causing the complexity.
next prev parent reply other threads:[~2018-11-18 17:24 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-11-18 11:17 Christian Brauner 2018-11-18 13:59 ` Daniel Colascione 2018-11-18 15:38 ` Andy Lutomirski 2018-11-18 15:53 ` Daniel Colascione 2018-11-18 16:17 ` Andy Lutomirski 2018-11-18 16:29 ` Daniel Colascione 2018-11-18 17:13 ` Andy Lutomirski 2018-11-18 17:17 ` Daniel Colascione 2018-11-18 17:43 ` Eric W. Biederman 2018-11-18 17:45 ` Andy Lutomirski 2018-11-18 17:56 ` Daniel Colascione 2018-11-18 16:33 ` Randy Dunlap 2018-11-18 16:48 ` Daniel Colascione 2018-11-18 17:09 ` Andy Lutomirski 2018-11-18 17:24 ` Daniel Colascione [this message] 2018-11-18 17:42 ` Andy Lutomirski 2018-11-18 17:51 ` Daniel Colascione 2018-11-18 18:28 ` Andy Lutomirski 2018-11-18 18:43 ` Daniel Colascione 2018-11-18 19:05 ` Aleksa Sarai 2018-11-18 19:44 ` Daniel Colascione 2018-11-18 20:15 ` Christian Brauner 2018-11-18 20:21 ` Daniel Colascione 2018-11-18 20:28 ` Andy Lutomirski 2018-11-18 20:32 ` Daniel Colascione 2018-11-19 1:43 ` Andy Lutomirski 2018-11-18 20:43 ` Christian Brauner 2018-11-18 20:54 ` Daniel Colascione 2018-11-18 21:23 ` Christian Brauner 2018-11-18 21:30 ` Christian Brauner 2018-11-19 0:31 ` Daniel Colascione 2018-11-19 0:40 ` Christian Brauner 2018-11-19 0:09 ` Aleksa Sarai 2018-11-19 0:53 ` Daniel Colascione 2018-11-19 1:16 ` Daniel Colascione 2018-11-19 16:13 ` Dmitry Safonov 2018-11-19 16:26 ` [PATCH] proc: allow killing processes via file descriptors (Larger pids) Eric W. Biederman 2018-11-19 16:27 ` [PATCH] proc: allow killing processes via file descriptors Daniel Colascione 2018-11-19 20:21 ` Aleksa Sarai 2018-11-19 2:47 ` Al Viro 2018-11-19 3:01 ` Andy Lutomirski 2018-11-18 17:41 ` Christian Brauner 2018-11-18 17:44 ` Andy Lutomirski 2018-11-18 18:07 ` Daniel Colascione 2018-11-18 18:15 ` Andy Lutomirski 2018-11-18 18:31 ` Daniel Colascione 2018-11-18 19:24 ` Christian Brauner 2018-11-19 0:08 ` Aleksa Sarai 2018-11-19 1:14 ` Daniel Colascione 2018-11-18 16:03 ` Daniel Colascione 2018-11-19 10:56 ` kbuild test robot 2018-11-19 14:15 ` David Laight 2018-11-19 15:49 ` Dave Martin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAKOZuesCKo4GH9fdum2EUFLrtTWam3aizcDQUn3-vCYg4T1P8w@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [PATCH] proc: allow killing processes via file descriptors' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions on how to clone and mirror all data and code used for this inbox