From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05668C43441 for ; Mon, 19 Nov 2018 01:43:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B78C82080F for ; Mon, 19 Nov 2018 01:43:54 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com header.i=@amacapital-net.20150623.gappssmtp.com header.b="Nx0Y+o3u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B78C82080F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=amacapital.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728034AbeKSMFs (ORCPT ); Mon, 19 Nov 2018 07:05:48 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:37621 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbeKSMFs (ORCPT ); Mon, 19 Nov 2018 07:05:48 -0500 Received: by mail-wr1-f65.google.com with SMTP id j10so16039286wru.4 for ; Sun, 18 Nov 2018 17:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zFUVbRW57D4CWvWZXYqKctEyl/YIEoGBj2tWSfPNsic=; b=Nx0Y+o3uBpl1MyP4CPaWEpKM/2/1Xmri472gY4KH5GJVwzebdW7WBVp+ak8jLb8AXz YVPz+tgGeZ6Kho9kNVeMZOsNdeaPf9vUwj9nGd2mkFzlunzk83a4u/8neiissH7qdKyh 0dF7HCXSpsMC0AABSmxMDRv6ZtdrJgKpJDBiHAliXqNQVa8EbQPsw84Mwetu9plF29kX DJFu5i3l1sEIXkgwL4Wg6tj++5ocDuKs61K8ap6HDpeZAceSW6T4hcGkzzifkSVqHZqc DoaP+Sdk1XCbFdM63wrx/EHFTJSZmGjf4A/Gz3Ke8rsyrmBQuQRoq/BZlx4Few6WHLS0 bEug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zFUVbRW57D4CWvWZXYqKctEyl/YIEoGBj2tWSfPNsic=; b=AZxrkQTMPM+ysLmjaKXuPvgKGq31XVxE89ERi9BXGtwnfuZY9Zy7zsXUtiCe5DZw7B aae/owwyv5DWBgAFYQ3Ybesgpl9llY5HLUnCATPvkvuX47k/+NqQZCnMfvJjbnZRWN/M cXNTxSYItuWEQsuu6hELoFsxXl8kU5f4yTOCn4amDg45KZ2UU1B+ytUHCPrMTeShqIxK X4F+b0mIaQ7orHbF8FBW50RpgCL8+9PrwwsYK+9S0ivu0M0G6SZ9L68AqJ6ODnP7m0Rl zUXQ/6wijdpPeke4IIV1uj3TE0B3q//2nSbWjUsQRNsRUSAFdK2ZbiHz2vyNJwMtOEIm gmzA== X-Gm-Message-State: AGRZ1gJEikngpllORHUf+Nr/ixUlRzsr9FB3OikTkKwuNr/V15i5BgjK 35KS1Rc891nmw5a6rxla09js/LKFQjUZxh/xIjVncQ== X-Google-Smtp-Source: AJdET5d11LlpNLmC0KstLwDUIRnPweGhfX29uh1fXtZSWWSwZg5ONdNnaDXy3r6bpFTJytDgGqXOp0CVaeyK48VKJOM= X-Received: by 2002:adf:e08c:: with SMTP id c12mr15597167wri.199.1542591827462; Sun, 18 Nov 2018 17:43:47 -0800 (PST) MIME-Version: 1.0 References: <20181118190504.ixglsqbn6mxkcdzu@yavin> <608F2959-800D-46EE-A7CD-8C972ACD2F02@amacapital.net> In-Reply-To: From: Andy Lutomirski Date: Sun, 18 Nov 2018 17:43:34 -0800 Message-ID: Subject: Re: [PATCH] proc: allow killing processes via file descriptors To: Daniel Colascione Cc: Aleksa Sarai , Andrew Lutomirski , Randy Dunlap , Christian Brauner , "Eric W. Biederman" , LKML , "Serge E. Hallyn" , Jann Horn , Andrew Morton , Oleg Nesterov , Al Viro , Linux FS Devel , Linux API , Tim Murray , Kees Cook , Jan Engelhardt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Nov 18, 2018 at 12:32 PM Daniel Colascione wrot= e: > > On Sun, Nov 18, 2018 at 12:28 PM, Andy Lutomirski w= rote: > >> That is, I'm proposing an API that looks like this: > >> > >> int process_kill(int procfs_dfd, int signo, const union sigval value) > >> > >> If, later, process_kill were to *also* accept process-capability FDs, > >> nothing would break. > > > > Except that this makes it ambiguous to the caller as to whether their c= urrent creds are considered. So it would need to be a different syscall or= at least a flag. Otherwise a lot of those nice theoretical properties go = away. > > Sure. A flag might make for better ergonomics. > > >> Yes, that's what I have in mind. A siginfo_t is small enough that we > >> could just store it as a blob allocated off the procfs inode or > >> something like that without bothering with a shmfs file. You'd be able > >> to read(2) the exit status as many times as you wanted. > > > > I think that, if the syscall in question is read(2), then it should wor= k *once* per struct file. Otherwise running cat on the file would behave v= ery oddly. > > Why? The file pointer would work normally. Can you explain the exact semantics? If I have an fd where read(2) returns the same 4-byte value every time read(2) is called, then cat will just return an infinite sequence of the same value. This is not a complete disaster, but it's not really a good thing. > > > Read and poll have the same problem as write: we can=E2=80=99t check ca= ps in read or poll either. > > Why not? Reading /proc/pid/stat does an access check today and > conditionally replaces the exit status with zero. And that's probably a bug. It's at least a giant kludge that we shouldn't = copy. Here is the general rule: the basic operations that are expected to treat file descriptors as capabilities *must* treat file descriptors as capabilities, at least for new APIs. This includes read(2), write(2), and poll(2). We should have an exceedingly good reason to check current's creds, mm, or anything else about current in those syscalls. There is a good reason for this: consider what happens if you type: sudo >/proc/PID/whatever or sudo