From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752468AbdK0Vb6 (ORCPT ); Mon, 27 Nov 2017 16:31:58 -0500 Received: from mail-qk0-f182.google.com ([209.85.220.182]:39742 "EHLO mail-qk0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751631AbdK0Vb4 (ORCPT ); Mon, 27 Nov 2017 16:31:56 -0500 X-Google-Smtp-Source: AGs4zMZonEXaKLi7XcCtP1vqrJWWxafyoJ+oe/b/SZoQkP+nDdb1OLNrcOvOLZJLJRzW7GMmb7IPhj38NKSROXoHDxg= MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> From: Djalal Harouni Date: Mon, 27 Nov 2017 22:31:54 +0100 Message-ID: Subject: Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure To: Linus Torvalds Cc: Kees Cook , Andy Lutomirski , Andrew Morton , "Luis R. Rodriguez" , James Morris , Ben Hutchings , Solar Designer , Serge Hallyn , Jessica Yu , Rusty Russell , Linux Kernel Mailing List , LSM List , "kernel-hardening@lists.openwall.com" , Jonathan Corbet , Ingo Molnar , "David S. Miller" , Network Development , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been pre-populated, and opening the device >> node is supposed to load the module. So _historically_ we did indeed >> load modules as normal users. But does that really happen any more? > > Sadly, it looks like bluetoothd actually does expect to load the > bt-proto-XYZ modules with no capabilities at all. > > So apparently we really do depend on not needing capabilities for > module loading. > > Oh well. Yes DCCP is unprivileged, tun and all tunneling, some md drivers, some crypto, and device drivers... fs modules can be loaded inside usernamespaces, and maybe when some request requires external symbols too... However tunneling helps to solve real usecases, so that's why the backward compatibility and opt-in. I do perfectly understand that opt-in is not the best choice, however these patchset includes a per process tree, and given that lot of code is running in containers and sandboxes, it is better than nothing. I will follow up later with patches to the major ones especially when we force the flag by default. Ubuntu was said to be owned in a past security contest due to this kind of things, and now since they have ubuntu snaps or apps they can set the flag, and others will follow. Thanks! > Linus -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Djalal Harouni Subject: Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure Date: Mon, 27 Nov 2017 22:31:54 +0100 Message-ID: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Kees Cook , Andy Lutomirski , Andrew Morton , "Luis R. Rodriguez" , James Morris , Ben Hutchings , Solar Designer , Serge Hallyn , Jessica Yu , Rusty Russell , Linux Kernel Mailing List , LSM List , "kernel-hardening@lists.openwall.com" , Jonathan Corbet , Ingo Molnar , "David S. Miller" , Network Development , Peter Zijlstra To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been pre-populated, and opening the device >> node is supposed to load the module. So _historically_ we did indeed >> load modules as normal users. But does that really happen any more? > > Sadly, it looks like bluetoothd actually does expect to load the > bt-proto-XYZ modules with no capabilities at all. > > So apparently we really do depend on not needing capabilities for > module loading. > > Oh well. Yes DCCP is unprivileged, tun and all tunneling, some md drivers, some crypto, and device drivers... fs modules can be loaded inside usernamespaces, and maybe when some request requires external symbols too... However tunneling helps to solve real usecases, so that's why the backward compatibility and opt-in. I do perfectly understand that opt-in is not the best choice, however these patchset includes a per process tree, and given that lot of code is running in containers and sandboxes, it is better than nothing. I will follow up later with patches to the major ones especially when we force the flag by default. Ubuntu was said to be owned in a past security contest due to this kind of things, and now since they have ubuntu snaps or apps they can set the flag, and others will follow. Thanks! > Linus -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: tixxdz@gmail.com (Djalal Harouni) Date: Mon, 27 Nov 2017 22:31:54 +0100 Subject: [PATCH v5 next 0/5] Improve Module autoloading infrastructure In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been pre-populated, and opening the device >> node is supposed to load the module. So _historically_ we did indeed >> load modules as normal users. But does that really happen any more? > > Sadly, it looks like bluetoothd actually does expect to load the > bt-proto-XYZ modules with no capabilities at all. > > So apparently we really do depend on not needing capabilities for > module loading. > > Oh well. Yes DCCP is unprivileged, tun and all tunneling, some md drivers, some crypto, and device drivers... fs modules can be loaded inside usernamespaces, and maybe when some request requires external symbols too... However tunneling helps to solve real usecases, so that's why the backward compatibility and opt-in. I do perfectly understand that opt-in is not the best choice, however these patchset includes a per process tree, and given that lot of code is running in containers and sandboxes, it is better than nothing. I will follow up later with patches to the major ones especially when we force the flag by default. Ubuntu was said to be owned in a past security contest due to this kind of things, and now since they have ubuntu snaps or apps they can set the flag, and others will follow. Thanks! > Linus -- tixxdz -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> From: Djalal Harouni Date: Mon, 27 Nov 2017 22:31:54 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH v5 next 0/5] Improve Module autoloading infrastructure To: Linus Torvalds Cc: Kees Cook , Andy Lutomirski , Andrew Morton , "Luis R. Rodriguez" , James Morris , Ben Hutchings , Solar Designer , Serge Hallyn , Jessica Yu , Rusty Russell , Linux Kernel Mailing List , LSM List , "kernel-hardening@lists.openwall.com" , Jonathan Corbet , Ingo Molnar , "David S. Miller" , Network Development , Peter Zijlstra List-ID: Hi Linus, On Mon, Nov 27, 2017 at 8:12 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 11:02 AM, Linus Torvalds > wrote: >> >> Now, the above will not necessarily work with a legacy /dev/ directory >> where al the nodes have been pre-populated, and opening the device >> node is supposed to load the module. So _historically_ we did indeed >> load modules as normal users. But does that really happen any more? > > Sadly, it looks like bluetoothd actually does expect to load the > bt-proto-XYZ modules with no capabilities at all. > > So apparently we really do depend on not needing capabilities for > module loading. > > Oh well. Yes DCCP is unprivileged, tun and all tunneling, some md drivers, some crypto, and device drivers... fs modules can be loaded inside usernamespaces, and maybe when some request requires external symbols too... However tunneling helps to solve real usecases, so that's why the backward compatibility and opt-in. I do perfectly understand that opt-in is not the best choice, however these patchset includes a per process tree, and given that lot of code is running in containers and sandboxes, it is better than nothing. I will follow up later with patches to the major ones especially when we force the flag by default. Ubuntu was said to be owned in a past security contest due to this kind of things, and now since they have ubuntu snaps or apps they can set the flag, and others will follow. Thanks! > Linus -- tixxdz