Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp930815imu; Thu, 13 Dec 2018 06:50:25 -0800 (PST) X-Google-Smtp-Source: AFSGD/Wdolqex5KxN0YIpLcFXezkir0/YUGhjnNB601q3UDytPnb2xr3xfhVgyWEHtnyef2kYdjN X-Received: by 2002:a17:902:34a:: with SMTP id 68mr24513210pld.268.1544712625358; Thu, 13 Dec 2018 06:50:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544712625; cv=none; d=google.com; s=arc-20160816; b=qKca0R9pjUhv5og9VvZq5i7qJ4UEr0J53tBWptjPd+IXHyuJCzZYX7tg7c1s9ZP3n2 KtKA7dh+b74AHVsyg7Li8p8gb4OeVOnuu23yZ+nkJ2SSEhF51u4PNvo7RkAxi/KZ/Zv0 otm2bAGwvhfkCEvAVfItkwxjhf82voF1gT2CuuKSmJjQTDGq5zjLWl03N+1O2/CUy+ZA RyB2dAzVW07pgu1TlyvchF1+ywLd+inwguAvcNgjxaQ+1bJa+S2hd73TLG309QINuzqh C6CSBawiaE3ZCQ756ym55OYvIcwIGUF/zaQG6Xq4+aWkPqRtd1Mpkgg7+f1DCU1zMZlE WZOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=fT0h/lay4UpJ7Yn9tjOWkFDL2xCToGPnPRb0mXb1Sts=; b=AvUGQeW+Zfr3tUECyjh06EfwD3PQNGSs1jcuTgil/acPuky1JNApNvQQGqXFVttt4U 0YSbEO0cgUcA8JcfQd6vwhzw7Vb+TWYBaY08FLjOT3GkPTplcQLsfwhjpKQTOn2V14ZS SIUhRu7fDIM8+KTKSRNyUppbiZ7oXJAi4X7ZD8soGuUMvgwKjLBd2ZVDsHWZ55voaBSV cydxOJtTaEc07E7FlczQVvn5TwDEs/+ZAwsX+r/lBDRlySqfpp6fio5t2iLoif3nPGFe CJdprMqx/kSYvf8W7+TMPZ4ifP6p4TTriQ2eWURA/N2ukJWDblZkA8X4xMeg09feVUj8 c2+A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ssi.gouv.fr header.s=20160407 header.b=BjZH5dC6; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u7si1684239pgg.357.2018.12.13.06.50.09; Thu, 13 Dec 2018 06:50:25 -0800 (PST) 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=@ssi.gouv.fr header.s=20160407 header.b=BjZH5dC6; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728921AbeLMOtM (ORCPT + 99 others); Thu, 13 Dec 2018 09:49:12 -0500 Received: from smtp-out.ssi.gouv.fr ([86.65.182.90]:52230 "EHLO smtp-out.ssi.gouv.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727551AbeLMOtL (ORCPT ); Thu, 13 Dec 2018 09:49:11 -0500 Received: from smtp-out.ssi.gouv.fr (localhost [127.0.0.1]) by smtp-out.ssi.gouv.fr (Postfix) with ESMTP id B4794D0006B; Thu, 13 Dec 2018 15:49:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ssi.gouv.fr; s=20160407; t=1544712557; bh=t4ZkM2bb49k43HJTH04W2MsitYuRiCp32PthRZd/wpM=; h=Subject:To:CC:References:From:Date:In-Reply-To:From:Subject; b=BjZH5dC6RomNffMo1aRB2qd7ETRmVRwb3O80beKZyGLeTYzynVNIu78HxbLsIb1/a 65XnS4vZ1T1e4Trm9SoeEGdmpQbN6bvAcDzw9UZcMPfS4cg/w3l2lG8XN7a2TNk6V8 bDAYaWjIfxlQcWzpTmk14kfe8ShUC/RmeOT13jewBLe3SrEIzFALjkOC/NXob3ps98 8yUpoA1170ifJvyDyenIERxzc710yHHqkiRw7Y0k6zoBDTkw8gY0ds0pb9pYMRDHsx xowu/c8l5kchULtz4G8cgS8wI32+bsQNKJS6z6ctuOWsbtL0HQOL/jWG5FavYwrPFn OvyGtxO3O7GiA== Subject: Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC To: Jann Horn , =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= CC: kernel list , Al Viro , James Morris , Jonathan Corbet , Kees Cook , Matthew Garrett , Michael Kerrisk-manpages , , , , , , , Kernel Hardening , Linux API , linux-security-module , References: <20181212081712.32347-1-mic@digikod.net> <20181212081712.32347-4-mic@digikod.net> From: =?UTF-8?Q?Micka=c3=abl_Sala=c3=bcn?= Message-ID: Date: Thu, 13 Dec 2018 15:49:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/12/2018 18:09, Jann Horn wrote: > On Wed, Dec 12, 2018 at 9:18 AM Mickaël Salaün wrote: >> Enable to either propagate the mount options from the underlying VFS >> mount to prevent execution, or to propagate the file execute permission. >> This may allow a script interpreter to check execution permissions >> before reading commands from a file. >> >> The main goal is to be able to protect the kernel by restricting >> arbitrary syscalls that an attacker could perform with a crafted binary >> or certain script languages. It also improves multilevel isolation >> by reducing the ability of an attacker to use side channels with >> specific code. These restrictions can natively be enforced for ELF >> binaries (with the noexec mount option) but require this kernel >> extension to properly handle scripts (e.g., Python, Perl). >> >> Add a new sysctl kernel.yama.open_mayexec_enforce to control this >> behavior. A following patch adds documentation. >> >> Signed-off-by: Mickaël Salaün >> Reviewed-by: Philippe Trébuchet >> Reviewed-by: Thibaut Sautereau >> Cc: Kees Cook >> Cc: Mickaël Salaün >> --- > [...] >> +/** >> + * yama_inode_permission - check O_MAYEXEC permission before accessing an inode >> + * @inode: inode structure to check >> + * @mask: permission mask >> + * >> + * Return 0 if access is permitted, -EACCES otherwise. >> + */ >> +int yama_inode_permission(struct inode *inode, int mask) > > This should be static, no? Right, it will be in the next series. The previous function (yama_ptrace_traceme) is not static though. > >> +{ >> + if (!(mask & MAY_OPENEXEC)) >> + return 0; >> + /* >> + * Match regular files and directories to make it easier to >> + * modify script interpreters. >> + */ >> + if (!S_ISREG(inode->i_mode) && !S_ISDIR(inode->i_mode)) >> + return 0; > > So files are subject to checks, but loading code from things like > sockets is always fine? As I said in a previous email, these checks do not handle fifo either. This is relevant in a threat model targeting persistent attacks (and with additional protections/restrictions). We may want to only whitelist fifo, but I don't get how a socket is relevant here. Can you please clarify? > >> + if ((open_mayexec_enforce & YAMA_OMAYEXEC_ENFORCE_MOUNT) && >> + !(mask & MAY_EXECMOUNT)) >> + return -EACCES; >> + >> + /* >> + * May prefer acl_permission_check() instead of generic_permission(), >> + * to not be bypassable with CAP_DAC_READ_SEARCH. >> + */ >> + if (open_mayexec_enforce & YAMA_OMAYEXEC_ENFORCE_FILE) >> + return generic_permission(inode, MAY_EXEC); >> + >> + return 0; >> +} >> + >> static struct security_hook_list yama_hooks[] __lsm_ro_after_init = { >> + LSM_HOOK_INIT(inode_permission, yama_inode_permission), >> LSM_HOOK_INIT(ptrace_access_check, yama_ptrace_access_check), >> LSM_HOOK_INIT(ptrace_traceme, yama_ptrace_traceme), >> LSM_HOOK_INIT(task_prctl, yama_task_prctl), >> @@ -447,6 +489,37 @@ static int yama_dointvec_minmax(struct ctl_table *table, int write, >> return proc_dointvec_minmax(&table_copy, write, buffer, lenp, ppos); >> } >> >> +static int yama_dointvec_bitmask_macadmin(struct ctl_table *table, int write, >> + void __user *buffer, size_t *lenp, >> + loff_t *ppos) >> +{ >> + int error; >> + >> + if (write) { >> + struct ctl_table table_copy; >> + int tmp_mayexec_enforce; >> + >> + if (!capable(CAP_MAC_ADMIN)) >> + return -EPERM; > > Don't put capable() checks in sysctls, it doesn't work. > I tested it and the root user can indeed open the file even if the process doesn't have CAP_MAC_ADMIN, however writing in the sysctl file is denied. Btw there is a similar check in the previous function (yama_dointvec_minmax). Thanks