Received: by 10.223.164.202 with SMTP id h10csp3696393wrb; Tue, 28 Nov 2017 15:55:49 -0800 (PST) X-Google-Smtp-Source: AGs4zMbEGY0QJJSbbup5fYfNcw+6JgKp9fspbzwmfaum2tI4cbjSNRoXj7ZRbINyF4jy6QULs03+ X-Received: by 10.98.86.70 with SMTP id k67mr921661pfb.214.1511913349251; Tue, 28 Nov 2017 15:55:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511913349; cv=none; d=google.com; s=arc-20160816; b=lvwyJWuVUYKM0DpJLcQ8vkfgHBcBa/DFrSRuHirQG7xEAwDx4K2I65OOOgwCLQFgRJ XzKvHsf8/jBE2F5XRSX8EkId8IthjFZC7f7itH/Ab9sXucdhFBDT9atZDIk90+6Yip96 X5pU0j9dgM3DZm1J88jqWmvauOlv7z8QFF9K/5Styk/q8q4C08vWmgusqDOhg4P9ZbSR jxpo8/JRFQ0AefLSvVAuXhJ4FsEJEv57TSNYJ9eNjOn87WqBujYz0SJkdianEsTKDcMo 24ad9oD9evAWfb+F4mrrYo4uL374ayPau7yb7je+tyM4Q7zt9deqGnF/fn1J64VlNFi+ 1LGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=JpMtAchiSrJ1r9P7c7biBIV77OKuhVbO99WiKKAQjso=; b=GuoLBemec7f6N0dMyfhPlaoQ3LgJLr/W9rzzsGRI3cPM3BBEYH4PV4NktFUj5brR9H QuMc1PaBXYJX74P4ArTJJMgASrRQzaEo6TuBdPHI1NdFR7FA7Z4soIP0RWP+jWzGgB+U yOp4pJN70Jn13oQOALpDkHbXhh3SQzNp09/K+3Xe3k9pPBgPAKPRgGnthKyB4W0soZgC g9uhe+ljN4hQICKbv8/jh2UGpyp0r+VsBpGY/mIVpJPxYEHxGHxpP0N2v58UVENCHIbT IX0JGn0anMR8jDeFhz6gDleC0f2bHWrPihcx2+k9vjJ0tweNFuGd5Nw09AVALD0QPCVS fe5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=pFr7lR8Y; 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=NONE 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 ay5si228360plb.457.2017.11.28.15.55.38; Tue, 28 Nov 2017 15:55:49 -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=@gmail.com header.s=20161025 header.b=pFr7lR8Y; 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=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753188AbdK1XxW (ORCPT + 70 others); Tue, 28 Nov 2017 18:53:22 -0500 Received: from mail-qk0-f195.google.com ([209.85.220.195]:43025 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751496AbdK1XxT (ORCPT ); Tue, 28 Nov 2017 18:53:19 -0500 Received: by mail-qk0-f195.google.com with SMTP id j207so2203506qke.10; Tue, 28 Nov 2017 15:53:18 -0800 (PST) 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; bh=JpMtAchiSrJ1r9P7c7biBIV77OKuhVbO99WiKKAQjso=; b=pFr7lR8YLkxMCST4uANdeuXc6Y9K2lzReTbzgyKVI/ke/y87DdH1soEUzDMPgzju6A LXi6DAzOvdFJzqZ0mhPoFlkIkqa7ukCdItI5TWlSBtAd0dPZF7rg0gpIxdxytF3ycJIB t5eAc0eGU7YbyyJvBbyCmPAOS2gdMlSdxfVODx5T2G67lN7xRyljmToQIh2Me/uSMZVe fQTS+28x2B2iEO77utCVLSZ/q2dufHx/mFDXVuPsul2c/4soaQf5LqfiHqaeUNBFuen6 Von0e/dwQEa3RzGFh7RITddh4taZxIzaONHjJ1kAtM/THVNdLetQBCeIRyflCKskWDrA RZ1g== 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; bh=JpMtAchiSrJ1r9P7c7biBIV77OKuhVbO99WiKKAQjso=; b=niOfaEI4FaVq6aWO+hm0EqNUjO/eay1haCAHOEoXtO8ZvTjc0MZ9LpOcKYUJghVz7I t/BVOCkG5bmtb3A+ZSBSjJU5If0uLd3qwjV+Kn5gUIVoQBQypbfQ1yP18ha8py0qbHmO kl8DbEwAVS/EIqO0qAawXkP5dPbYml39GazGZkxip0O5jhLT6bIhaMDofn8nJXJAMZkv sJRCzL+6BmTTMnW5AKMBwKbb6tE+7KHnGpLAhf9ZDDD9yxMlSHsXJE0ak/ErbI/6MwQV MwF5CeDUI+EcFyqZcSBKnrS1PSFaHCLLTReHPyTWSUXe7GA8g7UpTr9EdVgrtybrMHJR SQWg== X-Gm-Message-State: AJaThX4OnxMsrIKAVkBHaoT7H1likrQVw+6PWA3Es0AcPFNiGOhUCml+ NqIBUN/hKBaTRDjN5Zq/NO7AKcFDdvXd+R+yQJU= X-Received: by 10.55.40.76 with SMTP id o73mr1550648qkh.301.1511913198020; Tue, 28 Nov 2017 15:53:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.31.132 with HTTP; Tue, 28 Nov 2017 15:53:16 -0800 (PST) In-Reply-To: <20171128232320.22zo324g5wvo2lce@thunk.org> References: <1100603534.56586.1511871419952@ichabod.co-bxl> <20171128193243.4fymnjk7fplqw62x@thunk.org> <20171128232320.22zo324g5wvo2lce@thunk.org> From: Djalal Harouni Date: Wed, 29 Nov 2017 00:53:16 +0100 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules To: "Theodore Ts'o" , Kees Cook , Linus Torvalds , Djalal Harouni , Jonathan Corbet , James Morris , LSM List , Linux Kernel Mailing List , "kernel-hardening@lists.openwall.com" , Geo Kozey 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 Wed, Nov 29, 2017 at 12:23 AM, Theodore Ts'o wrote: > On Tue, Nov 28, 2017 at 01:33:40PM -0800, Kees Cook wrote: >> As I've said before, this isn't a theoretical attack surface. This >> year alone there have been three known-exploitable flaws exposed by >> autoloading: >> >> The exploit for CVE-2017-2636 uses int n_hdlc = N_HDLC; ioctl(fd, >> TIOCSETD, &n_hdlc) [1]. This is using the existing "tty-ldisc-" >> prefix, and is intentionally unprivileged. >> >> The exploit for CVE-2017-6074 uses socket(PF_INET6, SOCK_DCCP, >> IPPROTO_IP) [2]. This is using the existing proto prefix, and is >> intentionally unprivileged. > > So in these two cases, if the kernel was built w/o modules, and HDLC > and DCCP was built-in, you'd be screwed, then? > > Is the goal here to protect people using distro kernels which build > the world as modules, including dodgy pieces of kernel code that are > bug-ridden? > > If so, then presumably 90% of the problem you've cited can be done by > creating a script which takes a look of the modules that are normally > in use once the machine is in production, and then deleting everything > else? Correct? > > And yes, this will potentially break some users, but the security > folks who are advocating for the more aggressive version of this > change seem to be OK with breaking users, so they can do this without > making kernel changes. Good luck getting Red Hat and SuSE to accept > such a change, though.... The patches does not change default and make it easy for users and we have request for this, not all world is Red Hat / SuSE , I build embedded Linux for clients when I manage to have some, and I clearly would have set this to my clients since most of them won't be able to afford all the signing and complexity, now how I should allow modules load/unload replace with newer versions, but restrict some of their apps from triggering it, "modules_disabled=1" is not practical. I can't build a perfect version for every usecase, and they started to ship apps for IoT, even containers for IoT, yes they do it and they use the same os for various use cases! so it is not about those, even embedded vendors have one single shared layer that they use for all their products. For distros, the target is also containers and sandboxes, and they are already interested in it. P.S. please the cover letter already mentions that this is for Embedded and IoT. > - Ted -- tixxdz From 1585355914844586912@xxx Tue Nov 28 23:53:38 +0000 2017 X-GM-THRID: 1585240629942062556 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread