Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2129346imm; Mon, 28 May 2018 02:09:15 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrkRhMQkO/tDbZ/4H+oheX1zg1lY17Wh8RKNmQK/MPiZc4U8+oPK68s9etCEuAmLj0uLKx2 X-Received: by 2002:a17:902:6e4:: with SMTP id 91-v6mr12769806plh.63.1527498555925; Mon, 28 May 2018 02:09:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527498555; cv=none; d=google.com; s=arc-20160816; b=A6ikK+5ktpj1uV8iRHBpMerKSBdJ7m8sfbV15k68hnDUyrsdCR6iy/Vg6id0bnnYbz TMeDzvMhXLmD34GCjgzdA+rOKC4Nkj8wacnTiwtVRImfdIrMZqtTXCBYIikSsMFKQ2h4 3vzotp9k8Fj90Gn9hCZ8MYERf6MOkxESPCjsmej/S2RrGbWd/Z+8cUhh+eo6UY/swaQ/ lo9Qzy9Q0DyeSRZTceketUnO92ckrrfP3yNxaUiq9ULvRmF7jHoNF0lXJcQ0RBZKLpth 6FsEYu04FH6wm7WMBlCGB0teeHJJsimN5SvlnDmIxB0whdOb9e3OL4BJ8Xav9uiHJJB6 Bh4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=IabHfaRht8GbnuEHQJLnLkyMT4bItXvWvf00jQZ2C04=; b=j/+0Xqnyl3PLVlGAEUu+cu7yyIK9ICObVdK+KDkMl9qOrkoFDrNZG6qxgKVvAppam0 3h35SFat4weTj0lM4nYjprR8oZ16tdNEvW6rQb566hcsFtbth9DXQBgpX70YngKnGVw9 eqxWxpQ80h7hFI3pqMuf2f8/hQF4JHHbII8HA0yc/pO8SXtn75apb6t2UasyWwlYSJZ/ FyXzmdNuMdoow6e4f7J7c/fNyJML9AQHZDp5OywhraIXpVCCUf0JiUwZ5ySuc3Kw4v7Y tChsD7cF0lQcnEhSZbRVLh/aekTwF4GgD2MiiAB314VsS4SotAyPemYWLoThRRmxuxiR AVHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IzeBd+N2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1-v6si16303008pgn.281.2018.05.28.02.09.01; Mon, 28 May 2018 02:09:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=IzeBd+N2; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754346AbeE1JHE (ORCPT + 99 others); Mon, 28 May 2018 05:07:04 -0400 Received: from mail-ot0-f194.google.com ([74.125.82.194]:34636 "EHLO mail-ot0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754291AbeE1JHA (ORCPT ); Mon, 28 May 2018 05:07:00 -0400 Received: by mail-ot0-f194.google.com with SMTP id i5-v6so12779491otf.1 for ; Mon, 28 May 2018 02:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IabHfaRht8GbnuEHQJLnLkyMT4bItXvWvf00jQZ2C04=; b=IzeBd+N2xLh62Rl0PLr5kaJspR0cMM3Sy2bbZBt8uxqTL4/p0lpf3ocC9jbkBDW5Nm 96Mi4z0gvKoDI4AowaeWXkfTMI7BicidQwRlBhwhjGpUP8vkaiJuzq46uF8ncVo7niRV WfmQ07SxUgUzHre6BU5niwllP5MjhVnV1Dnnylr7+yINID86ioPVxJz3mNzzhX6sb2ia 1CTH63bzMmCg31AOBQtIoT0H+8jzgrI/zskrQTvBnh5HKw9ZE6YvoxDSwY6LIrDuoAW1 iXlEseH1qemNYVmR8k2h8ZKYJYd2upK0oH0Y5BasJO6JeN0zkZ0EfIAXRP2DkX/gZ8Q3 9IRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IabHfaRht8GbnuEHQJLnLkyMT4bItXvWvf00jQZ2C04=; b=W54ieVowfhLAOr0Bj/pySNGQyR6lQHBgJltcboFN5ebe7dl7CEFZNprbG3cm81EmcO HTCXqK1yzCqv5yAjxvYTVDQ7MTfERahFJ9klX3sdQzDjnDqehTm78DNt4AUIU4GHXFx7 BSjG795z4nrW3lgjztHeUrRJ7VyN/ZfDRbNmt7cMAW1GNhLpCrcSmZm/po7rZSCKU3B7 lsM2dbxyuykg+GN3fs75xej/zAD3Et5tTvOCrZzV6SsmDQglff/x5XghzKYBHjfgn7J+ pxWmbC0gsRxN4GxEvOhAMOwgJf6DnC+vW3N+ItOgyhLGZaNc0s+NBefZICBBZ+8Gzgq2 3XQw== X-Gm-Message-State: ALKqPwfsKnGtuaEmlZMD19tUX4e+oC0k+/wqcK5AUm88P/tKQPTWCSci 4K84mkf7DdwFcAIJBl7uJwk2K48gQT6OulLtAgODHg== X-Received: by 2002:a9d:210a:: with SMTP id i10-v6mr7641894otb.72.1527498419234; Mon, 28 May 2018 02:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:9190:0:0:0:0:0 with HTTP; Mon, 28 May 2018 02:06:38 -0700 (PDT) In-Reply-To: <1527346246-1334-1-git-send-email-s.mesoraca16@gmail.com> References: <1527346246-1334-1-git-send-email-s.mesoraca16@gmail.com> From: Jann Horn Date: Mon, 28 May 2018 11:06:38 +0200 Message-ID: Subject: Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem To: Salvatore Mesoraca Cc: Kernel Hardening , linux-security-module , kernel list , Linux-MM , Andrew Morton , Alexey Dobriyan , Akinobu Mita , Dmitry Vyukov , Arnd Bergmann , Davidlohr Bueso , Kees Cook Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, May 26, 2018 at 4:50 PM, Salvatore Mesoraca wrote: > Prevent a task from opening, in "write" mode, any /proc/*/mem > file that operates on the task's mm. > /proc/*/mem is mainly a debugging means and, as such, it shouldn't > be used by the inspected process itself. > Current implementation always allow a task to access its own > /proc/*/mem file. > A process can use it to overwrite read-only memory, making > pointless the use of security_file_mprotect() or other ways to > enforce RO memory. > > Signed-off-by: Salvatore Mesoraca > --- > fs/proc/base.c | 25 ++++++++++++++++++------- > fs/proc/internal.h | 3 ++- > fs/proc/task_mmu.c | 4 ++-- > fs/proc/task_nommu.c | 2 +- > 4 files changed, 23 insertions(+), 11 deletions(-) > > diff --git a/fs/proc/base.c b/fs/proc/base.c > index 1a76d75..01ecfec 100644 > --- a/fs/proc/base.c > +++ b/fs/proc/base.c > @@ -762,8 +762,9 @@ static int proc_single_open(struct inode *inode, struct file *filp) > .release = single_release, > }; > > - > -struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode) > +struct mm_struct *proc_mem_open(struct inode *inode, > + unsigned int mode, > + fmode_t f_mode) > { > struct task_struct *task = get_proc_task(inode); > struct mm_struct *mm = ERR_PTR(-ESRCH); > @@ -773,10 +774,20 @@ struct mm_struct *proc_mem_open(struct inode *inode, unsigned int mode) > put_task_struct(task); > > if (!IS_ERR_OR_NULL(mm)) { > - /* ensure this mm_struct can't be freed */ > - mmgrab(mm); > - /* but do not pin its memory */ > - mmput(mm); > + /* > + * Prevent this interface from being used as a mean > + * to bypass memory restrictions, including those > + * imposed by LSMs. > + */ > + if (mm == current->mm && > + f_mode & FMODE_WRITE) > + mm = ERR_PTR(-EACCES); > + else { > + /* ensure this mm_struct can't be freed */ > + mmgrab(mm); > + /* but do not pin its memory */ > + mmput(mm); > + } > } > } I don't have an opinion on the overall patch, but this part looks buggy: In the error path, you set `mm` to an error pointer, but you still own the reference that mm_access() took on the old `mm`. The error path needs to call `mmput(mm)`.