linux-kernel - Re: [PATCH] proc: allow killing processes via file descriptors

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:   Sun, 18 Nov 2018 19:01:18 -0800
From:   Andy Lutomirski <luto@...nel.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Andrew Lutomirski <luto@...nel.org>,
        Daniel Colascione <dancol@...gle.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Christian Brauner <christian@...uner.io>,
        "Eric W. Biederman" <ebiederm@...ssion.com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Serge E. Hallyn" <serge@...lyn.com>, Jann Horn <jannh@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>,
        Aleksa Sarai <cyphar@...har.com>,
        Linux FS Devel <linux-fsdevel@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Tim Murray <timmurray@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        Jan Engelhardt <jengelh@...i.de>
Subject: Re: [PATCH] proc: allow killing processes via file descriptors

On Sun, Nov 18, 2018 at 6:47 PM Al Viro <viro@...iv.linux.org.uk> wrote:
>
> On Sun, Nov 18, 2018 at 09:42:35AM -0800, Andy Lutomirski wrote:
>
> > Now here's the kicker: if the "running program" calls execve(), it
> > goes away.  The fd gets some sort of notification that this happened
>
> Type error, parser failed.
>
> Define "fd", please.  If it's a "file descriptor", thank you do playing,
> you've lost.  That's not going to work.  If it's "opened file" (aka
> "file description" in horrible POSIXese), who's going to get notifications
> and what kind of exclusion are you going to use?

What I meant was: a program that has one of these fds would be able to
find out that an execve() happened and the program needs to refresh
its access to the target task.  This could be as simple as POLLHUP
and, if needed, some syscall indicating exactly why we got POLLHUP
(e.g. execve vs exit).

There would be some sort of indication that a program that holds an fd
pointing at an "opened file" could get -- probably poll() would return
some status indicating that execve() happened and our capability is
gone, and, if needed