linux-kernel - Re: [RFC PATCH] Implement /proc/pid/kill

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Oct 2018 23:55:17 +0000
From:   Daniel Colascione <dancol@...gle.com>
To:     Christian Brauner <christian.brauner@...onical.com>
Cc:     Joel Fernandes <joel@...lfernandes.org>,
        Aleksa Sarai <cyphar@...har.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Tim Murray <timmurray@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [RFC PATCH] Implement /proc/pid/kill

On Tue, Oct 30, 2018 at 11:23 PM, Christian Brauner
<christian.brauner@...onical.com> wrote:
> On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione <dancol@...gle.com> wrote:
>> I think Aleksa's larger point is that it's useful to treat processes
>> as other file-descriptor-named, poll-able, wait-able resources.
>> Consistency is important. A process is just another system resource,
>> and like any other system resource, you should be open to hold a file
>> descriptor to it and do things to that process via that file
>> descriptor. The precise form of this process-handle FD is up for
>> debate. The existing /proc/$PID directory FD is a good candidate for a
>> process handle FD, since it does almost all of what's needed. But
>> regardless of what form a process handle FD takes, we need it. I don't
>> see a case for continuing to treat processes in a non-unixy,
>> non-file-descriptor-based manner.
>
> That's what I'm proposing in the API for which I'm gathering feedback.
> I have presented parts of this in various discussions at LSS Europe last week
> and will be at LPC.
> We don't want to rush an API like this though. It was tried before in
> other forms
> and these proposals didn't make it.

And I'm looking forward to that proposal.

AIUI, one of the reasons previous proposals in this area failed is
that they'd have their process handles pin entire task_struct
instances and keep PID-table entries reserved as long as handles were
kept open. If you keep a PID reserved as long as you have an open
handle to a process, then existing PID-taking interfaces become
race-free automatically, so there's little new API. (This
PID-preserving approach is the one Windows uses, FWIW.)

An alternate approach is that have your process "handle" reference a
struct pid instead of a numeric PID or task_struct. You can't prevent
PID reuse this way, but you can at least distinguish between different
processes that have used the same PID, so you still get race freedom.
The downside of this approach is that since you don't prevent PID
reuse, existing PID-accepting interfaces remain racy and so, since you
need to let people name processes by process handle instead of by PID
whenever they want to do something with a process, you need to provide
an FD-accepting version of each current pid_t-accepting system call,
e.g. ptrace.