From: Daniel Colascione <email@example.com> To: Andy Lutomirski <firstname.lastname@example.org> Cc: Randy Dunlap <email@example.com>, Christian Brauner <firstname.lastname@example.org>, "Eric W. Biederman" <email@example.com>, LKML <firstname.lastname@example.org>, "Serge E. Hallyn" <email@example.com>, Jann Horn <firstname.lastname@example.org>, Andrew Morton <email@example.com>, Oleg Nesterov <firstname.lastname@example.org>, Aleksa Sarai <email@example.com>, Al Viro <firstname.lastname@example.org>, Linux FS Devel <email@example.com>, Linux API <firstname.lastname@example.org>, Tim Murray <email@example.com>, Kees Cook <firstname.lastname@example.org>, Jan Engelhardt <email@example.com> Subject: Re: [PATCH] proc: allow killing processes via file descriptors Date: Sun, 18 Nov 2018 09:51:48 -0800 [thread overview] Message-ID: <CAKOZuevVk_aH_2TuiNcmxgMa+gHXMBXz6Uu5a6TDjoxjhaE36g@mail.gmail.com> (raw) In-Reply-To: <CALCETrUeNZPfrSYa9vH5Ukrk1Y+Kb9GkZOh6LkqG6Z9NpK5P0w@mail.gmail.com> On Sun, Nov 18, 2018 at 9:42 AM, Andy Lutomirski <firstname.lastname@example.org> wrote: > On Sun, Nov 18, 2018 at 9:24 AM Daniel Colascione <email@example.com> wrote: >> 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. > > Sounds reasonable to me. Except for the obvious turd that, if you > open /proc/PID/whatever, and the process calls execve(), then the > resulting semantics are awkward at best. A process calling execve does not give up its logical identity. Lots of programs exec themselves, e.g., to reload configuration. >> > 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. > > I'm not entirely sure that ship has sailed. In the kernel, we already > have a bit of a distinction between a pid (and tid, etc -- I'm > referring to struct pid) and a task. If we make a new > process-management API, we could put a distinction like this into the > API. It would be a disaster to have different APIs give callers a different idea of process identity over its lifetime. The precedent is well-established that execve and setreuid do not change a process's identity. Invaliding some identifiers but not others in response to supposedly-internal things a process might do under rare circumstances is creating a bug machine.. > setresuid() has no effect > here -- if you have W access to the process and the process calls > setresuid(), you still have W access. Now you've created a situation in which an operation that security policy previously blocked now becomes possible, invaliding previous designs based on the old security invariant. That's the definition of introducing a security hole.
next prev parent reply other threads:[~2018-11-18 17:51 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 2018-11-18 17:42 ` Andy Lutomirski 2018-11-18 17:51 ` Daniel Colascione [this message] 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=CAKOZuevVk_aH_2TuiNcmxgMa+gHXMBXz6Uu5a6TDjoxjhaE36g@mail.gmail.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 \ --firstname.lastname@example.org \ --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