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]

Message-ID: <CAKOZueuRbYh5dKoT4R6_t87yKZR_bzX+7s4KevvSmfcBk+YeYw@mail.gmail.com>
Date:   Thu, 1 Nov 2018 15:50:20 +0000
From:   Daniel Colascione <dancol@...gle.com>
To:     David Laight <David.Laight@...lab.com>
Cc:     Oleg Nesterov <oleg@...hat.com>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Tim Murray <timmurray@...gle.com>,
        Joel Fernandes <joelaf@...gle.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Christian Brauner <christian.brauner@...onical.com>
Subject: Re: [RFC PATCH] Implement /proc/pid/kill

On Thu, Nov 1, 2018 at 11:53 AM, David Laight <David.Laight@...lab.com> wrote:
> From: Sent: 31 October 2018 13:28
> ...
>> * I actually have a local variant of the patch that would have you
>> open "/proc/$PID/kill/$SIGNO" instead, since different signal numbers
>> have different permission checks.
>
> I think you'd need the open() to specify some specific unusual
> open modes.
> Otherwise it'll be far too easy for scripts (and people) to
> accidentally send every signal to every process.

I think the /proc/$PID/kill/$SIGNO idea is dead anyway, and even
dead-er since Linus banned write() for commands. (Looks like we'll
need a system call after all.)

That said, for the record, I was talking about the *write* sending the
signal, not the open, so grep of /proc wouldn't send random signals to
every process.

> Also think of the memory footprint.

Proc inodes are created on-demand, so AIUI, the memory overhead of
heaving a per-FD directory of stuff isn't very high.