From: Andy Lutomirski <firstname.lastname@example.org> To: Daniel Colascione <email@example.com> Cc: Andrew Lutomirski <firstname.lastname@example.org>, 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:42:35 -0800 [thread overview] Message-ID: <CALCETrUeNZPfrSYa9vH5Ukrk1Y+Kb9GkZOh6LkqG6Z9NpK5P0w@mail.gmail.com> (raw) In-Reply-To: <CAKOZuesCKo4GH9fdum2EUFLrtTWam3aizcDQUn3-vCYg4T1P8w@mail.gmail.com> On Sun, Nov 18, 2018 at 9:24 AM Daniel Colascione <firstname.lastname@example.org> 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. > > > 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. As a straw-man proposal (highly incomplete and probably wrong, but maybe it gets the idea across): Have a way to get an fd that refers to a "running program". (I'm calling it that to distinguish it from "task" and "pid", both of which already mean something.) You'd be able to open such an fd given a pid, and your permissions would be checked at that time. R access means you can read the running program's memory and otherwise introspect it. W means you can modify it's memory and otherwise mess with it. X means you can send it signals. We might need more bits to really do this right. Now here's the kicker: if the "running program" calls execve(), it goes away. The fd gets some sort of notification that this happened and there's an API to get a handle to the new running program *if the caller has the appropriate permissions*. setresuid() has no effect here -- if you have W access to the process and the process calls setresuid(), you still have W access. To make this fully useful, we'd probably want to elaborate it with a race-free way to track all descendents and, if needed, kill them all, subject to permissions. This API ought to be extensible to replace ptrace() eventually. Does this seem like a reasonable direction to go in?
next prev parent reply other threads:[~2018-11-18 17:42 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 [this message] 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=CALCETrUeNZPfrSYa9vH5Ukrk1Y+Kb9GkZOh6LkqG6Z9NpK5P0w@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