Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2146476imm; Mon, 28 May 2018 02:34:17 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrJzHjT6rWiV7ZER+kRWNmYXN67eH2rFiESCL18gY61he3f24/w9ffSA8V78mbVDLfdDaAr X-Received: by 2002:a17:902:ab8b:: with SMTP id f11-v6mr12671138plr.372.1527500057012; Mon, 28 May 2018 02:34:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527500056; cv=none; d=google.com; s=arc-20160816; b=tqw7ERuz2UiTuMYfAq8NYGoPNoSJ+3u31tZ2zEH7UrDv4UqGcjFNEZIROFR8akYxlF rA0juaAQo+9PEIqRFfnO1nqLWsIMVMMb8WGKX6biNE5iu3drK6DEtr48GKCjJsJWJLWF m0EPvGC2RyVj7MhzEThwkKpUHjKsLgq14K2HFP8P3McRGSrLB7xssxdKiwUMwhQ/5ugx hQSnhunKZdtvHLGuqwuKLVU0CxHdNSj+wK7PGiabnfyT2bLfolJhs6rnYnMIN/MNY/fm vONC5hyJ1g2s9J4Kar84/KWTfRp8wgvrwQaNhDLqOQ5xWirzuFhQdzQgXQqX1ROUR05t YOhg== 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=fZepYyDpSE0fwI6MUThYHxg7kvmuuMOwfMO8MMN7R3I=; b=fMV0B6HSXp9V/vZRIE9/CvkO0kr355/OlEUzF52kPXtSWLYreWJF+dUfAp0IUKpt2R a1hlVongRJR8k+KDfiLhOBa7aAc+l0cxNV7hUJa6b1BQ2CKp59ZWxOVkgh1/8wbOhVHG C7j1ZzEQ89yONo5R9Cp8RgECqeTghLduIC45HO78ifR6lYytTA/B1mw/sZjJpnl7krBD ATg/aL1ATAbukKSvJv0vobtcLAAYWVT4sd98eREKdT59lBgKeq1jr7MNd2UrrMhghXHI 0xpSUAS+llXKIlNkKLwb5L9UrnTW/sOynXy3RAUY9sIylcySDjOUhcV7PFiK6e9HO+oy nmbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=qCgQ2oX8; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p84-v6si29730898pfa.180.2018.05.28.02.34.02; Mon, 28 May 2018 02:34:16 -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=@gmail.com header.s=20161025 header.b=qCgQ2oX8; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932104AbeE1Jd5 (ORCPT + 99 others); Mon, 28 May 2018 05:33:57 -0400 Received: from mail-vk0-f67.google.com ([209.85.213.67]:38408 "EHLO mail-vk0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754090AbeE1Jdy (ORCPT ); Mon, 28 May 2018 05:33:54 -0400 Received: by mail-vk0-f67.google.com with SMTP id u8-v6so6711280vku.5; Mon, 28 May 2018 02:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fZepYyDpSE0fwI6MUThYHxg7kvmuuMOwfMO8MMN7R3I=; b=qCgQ2oX8D73gnT74qJn6QhjzM9EA4YoARyphZe8aMXbnJBcC4nfnm93SGEBJyWTvXO wJCq7ktKJxx29ucp6k6r/w5JvfmMDN9RcDhfsWygKFi6RELOdcAIm3TBiukZFGIJJpjz ff1mkaCjmzdCr7AmXf+qh/Y6WUvXLaE0FbSgD1ic2xogKulBtVUKdI7sFDib1rME92Ik ak/+2UGCyFIjZkHFepQslbTQly1fbi3L3YIl1YUrNvdiM5inAxNYHEOCWHe0gcX80Wwd ax+d8upaINY6m9ZiSrbGqvUqH6wM8aHbGgja66jkzVHlyy6Bi/SHqKSZ5wmHAsKK5FGS 3bcA== 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=fZepYyDpSE0fwI6MUThYHxg7kvmuuMOwfMO8MMN7R3I=; b=P+fbcTF59OkM56fwUCjmTZjRycrMsRBynjz3d1QIMNsZf0tE4mdVCPmvYqhmn+YWlC bTgzWtoe66aRbNvzjI3xY7VkwY/kZy+92i/o3sZzVTlaoDi0kUi0VMmIiexvkzqxRZVb va6uS8c4JihCsgNZIgmi/iYjkNm4iC8fuX8lNulBsS2ZiRl52lZ0NGCzTflcptg6lSfR hCSotHMaMiaPJCVQBHOlLZfFc/IpouvmBAC0VEiHvI/UUTmLTOnsFaAl7y+OMOgnqX8r 4pfYn2xOO/cPd20nQvk0LZCUYMEU0xtWYhli//2jbI1OsJUsy8O/f8/rPQ14sVjCvelZ K8LA== X-Gm-Message-State: ALKqPwdAw+5EbqlTIKAvt8P/+qy8tQC8ZGL725j/3RHydby6+5CKItFl zCZpMQ7jVQ9UMADgY2u+fQx6ZapC5M6AMMZnIVw= X-Received: by 2002:a1f:a7c7:: with SMTP id q190-v6mr7217645vke.5.1527500033354; Mon, 28 May 2018 02:33:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a67:381:0:0:0:0:0 with HTTP; Mon, 28 May 2018 02:33:33 -0700 (PDT) In-Reply-To: References: <1527346246-1334-1-git-send-email-s.mesoraca16@gmail.com> From: Salvatore Mesoraca Date: Mon, 28 May 2018 11:33:33 +0200 Message-ID: Subject: Re: [PATCH] proc: prevent a task from writing on its own /proc/*/mem To: Jann Horn 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 2018-05-28 11:06 GMT+02:00 Jann Horn : > 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)`. You are absolutely right, Thank you, Salvatore