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=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 2C616C43387 for ; Thu, 3 Jan 2019 11:17:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E32E020815 for ; Thu, 3 Jan 2019 11:17:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="T6PleOdA" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731074AbfACLRr (ORCPT ); Thu, 3 Jan 2019 06:17:47 -0500 Received: from mail-oi1-f195.google.com ([209.85.167.195]:36749 "EHLO mail-oi1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729990AbfACLRq (ORCPT ); Thu, 3 Jan 2019 06:17:46 -0500 Received: by mail-oi1-f195.google.com with SMTP id x23so27421944oix.3 for ; Thu, 03 Jan 2019 03:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VQcPxfSwbKHal4eWi9/k1XS4dY35WSsLnXPxD3MpobU=; b=T6PleOdAW7jaKUX3gNidSFglPIPfLu+3K/DlD5Q2mS4mRTBLBU136P687GkVMoWY2z J7kFxwviMe0uGMtVow3IgpPv4vPOsdX4KZWZbtdLn2uaxTC5Ogo/mvMaOAjmNa+fMweb y7HuBE0LIhNtsRMLl8ENZtQlaupCvWzo+mV2IKdmThKFuzVdXOIuaVdMrnYMRQvzah3M aBTvMaMn5nGRrmqlrHEvv5OSlf+CrjzDX+xXfsnreX4SH2qGEOkIezkEvL50q9H5Po6z a4PbOSODE/LkIr7JBhW5B+86ZGPsOeyOuyhy22rFj2MTR6w3z20QjWyn7OOjcQLmMBg8 REkw== 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=VQcPxfSwbKHal4eWi9/k1XS4dY35WSsLnXPxD3MpobU=; b=co5RF3GXVxR2GnmaYsguV6JxUN81rQ6p2zjP+hMUWOPlWMHiOJ+BeLeZ6/ETShUeRA +M7QBvLmgQI3nFWvxYqYJ71E/rN2qxsAWzfvPw++bDNsk+KckaX27DXeiseEb0m6Vm4H zWa0Dsw3iDS+QwQtHppRD4GQmAIx/X6JlM15mawRo/Se77Uwo89q6grfCODQw2ponpTF imcQ7Rd8R5/RFcedpXSvzdW/QtNo88MRq7wjQ8B57BUTJdsVv9a2InsU47WsbB8S/STx l3xFfip1F5Zp2vBLLCztKKRJQKar+9GF5vlqUAqrS+4nV1mjrX+jQJnwed8En4KG9lx5 NqoA== X-Gm-Message-State: AA+aEWZFyTsNu6LC2b679jIWRZawflnEB158dy3dzzz6izcF9KwxpuFe Pt3dYE7DLHhxCoK5SspvyXfVoSBBAopvZCkZBSym5g== X-Google-Smtp-Source: AFSGD/XiwJGaiKByr8OTBdwiBgw1TNuFRBMqiz3NETNZjlIQQcbdQvO6wAH9FZ/4kat3ZhktbLlHDDgtyooDQHiPL/c= X-Received: by 2002:aca:ad14:: with SMTP id w20mr30453747oie.3.1546514265488; Thu, 03 Jan 2019 03:17:45 -0800 (PST) MIME-Version: 1.0 References: <20181212081712.32347-1-mic@digikod.net> <20181212081712.32347-4-mic@digikod.net> In-Reply-To: From: Jann Horn Date: Thu, 3 Jan 2019 12:17:18 +0100 Message-ID: Subject: Re: [RFC PATCH v1 3/5] Yama: Enforces noexec mounts or file executability through O_MAYEXEC To: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= Cc: =?UTF-8?B?TWlja2HDq2wgU2FsYcO8bg==?= , kernel list , Al Viro , James Morris , Jonathan Corbet , Kees Cook , Matthew Garrett , Michael Kerrisk-manpages , zohar@linux.ibm.com, philippe.trebuchet@ssi.gouv.fr, shuah@kernel.org, thibaut.sautereau@ssi.gouv.fr, vincent.strubel@ssi.gouv.fr, yves-alexis.perez@ssi.gouv.fr, Kernel Hardening , Linux API , linux-security-module , linux-fsdevel@vger.kernel.org, Andy Lutomirski Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: owner-linux-security-module@vger.kernel.org Precedence: bulk List-ID: On Thu, Dec 13, 2018 at 3:49 PM Micka=C3=ABl Sala=C3=BCn wrote: > On 12/12/2018 18:09, Jann Horn wrote: > > On Wed, Dec 12, 2018 at 9:18 AM Micka=C3=ABl Sala=C3=BCn wrote: > >> Enable to either propagate the mount options from the underlying VFS > >> mount to prevent execution, or to propagate the file execute permissio= n. > >> 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 binar= y > >> 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. [...] > >> +{ > >> + 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 clari= fy? I don't think that there's a security problem here. I just think it's weird to have the extra check when it seems to me like it isn't really necessary - nobody is going to want to execute a socket or fifo anyway, right? > > > >> + if ((open_mayexec_enforce & YAMA_OMAYEXEC_ENFORCE_MOUNT) && > >> + !(mask & MAY_EXECMOUNT)) > >> + return -EACCES; > >> + > >> + /* > >> + * May prefer acl_permission_check() instead of generic_permis= sion(), > >> + * 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 =3D= { > >> + 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, in= t 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). It's still wrong. If an attacker without CAP_MAC_ADMIN opens the sysctl file, then passes the file descriptor to a setcap binary that has CAP_MAC_ADMIN as stdout/stderr, and the setcap binary writes to it, then the capable() check is bypassed. (But of course, to open the sysctl file in the first place, you'd need to be root (uid 0), so the check doesn't really matter.)