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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 31 Oct 2018 16:10:07 +0100
From:   Oleg Nesterov <oleg@...hat.com>
To:     Daniel Colascione <dancol@...gle.com>
Cc:     "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 10/31, Daniel Colascione wrote:
>
> > perhaps it would be simpler to do
> >
> >         my_cred = override_creds(file->f_cred);
> >         kill_pid(...);
> >         revert_creds(my_cred);
>
> Thanks for the suggestion. That looks neat, but it's not quite enough.
> The problem is that check_kill_permission looks for
> same_thread_group(current, t) _before_ checking kill_of_by_cred,

Yes, you are right.

Looks like kill_pid_info_as_cred() can find another user, but probably
it needs some changes with or without /proc/pid/kill ...

> There's another problem though: say we open /proc/pid/5/kill *, with
> proc 5 being an ordinary unprivileged process, e.g., the shell. At
> open(2) time, the access check passes. Now suppose PID 5 execve(2)s
> into a setuid process. The kill FD is still open, so the kill FD's
> holder can send a signal

Confused... why? kill_ok_by_cred() should fail?

Oleg.