From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753182AbdK0Vlf (ORCPT ); Mon, 27 Nov 2017 16:41:35 -0500 Received: from mail-qk0-f196.google.com ([209.85.220.196]:41001 "EHLO mail-qk0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752486AbdK0Vlc (ORCPT ); Mon, 27 Nov 2017 16:41:32 -0500 X-Google-Smtp-Source: AGs4zMa5v/zqYquAOO9l+76Uu2vW04NAUlqfoahXSpY7hjA8HoNy3IGZZ1Q84ZV6VH3oFLJgDXY5s1rZ/3Wh3ayXBoM= MIME-Version: 1.0 In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> From: Djalal Harouni Date: Mon, 27 Nov 2017 22:41:31 +0100 Message-ID: Subject: Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules 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 7:44 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capability and the 'netdev' module prefix to the >> capability subsystem as it was suggested. > > This is the kind of complexity that I wonder if it's worth it at all. > > Nobody sane actually uses those stupid capability bits. Have you ever > actually seen it used in real life? Yes they are complicated even for developers, and normal users do not understand them, however yes every sandbox and container is exposing them to endusers directly, they are documented! so yes CAP_SYS_MODULE is exposed but it does not cover autoloading. However, we are trying hard to abstract some semantics that are easy to grasp, we are mutating capabilities and seccomp to have an abstracted "yes/no" options for our endusers. Now, if you are referring to kernel code, the networking subsystem is using them and I don't want to break any assumption here. There is still the request_module(), the request_module_cap() was suggested so networking code later won't have to do the checks on its own, and maybe it can be consistent in the long term. The phonet sockets even needs CAP_SYS_ADMIN... > > They were a mistake, and we should never have done them - another case > of security people who think that complexity == security, when in > reality nobody actually wants the complexity or is willing to set it > up and manage it. Alright, but I guess we are stuck, is there something better on how we can do this or describe this ? Please note in these patches, the mode is specifically described as: * allowed: for backward compatibility (I would have done without it) * privileged: which includes capabilities (backward compatibility too) or we can add what ever in the future * disabled: even for privileged. So I would have preferred if it is something like "yes/no" but... However in userspace we will try hard to hide this complexity and the capability bits. Now I can see that the code comments and doc refer to privileged with capabilities a lot, where we can maybe update that doc and code to less state that privileged means capabilities ? Suggestions ? Thanks! > Linus -- tixxdz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Djalal Harouni Subject: Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules Date: Mon, 27 Nov 2017 22:41:31 +0100 Message-ID: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-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 7:44 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capability and the 'netdev' module prefix to the >> capability subsystem as it was suggested. > > This is the kind of complexity that I wonder if it's worth it at all. > > Nobody sane actually uses those stupid capability bits. Have you ever > actually seen it used in real life? Yes they are complicated even for developers, and normal users do not understand them, however yes every sandbox and container is exposing them to endusers directly, they are documented! so yes CAP_SYS_MODULE is exposed but it does not cover autoloading. However, we are trying hard to abstract some semantics that are easy to grasp, we are mutating capabilities and seccomp to have an abstracted "yes/no" options for our endusers. Now, if you are referring to kernel code, the networking subsystem is using them and I don't want to break any assumption here. There is still the request_module(), the request_module_cap() was suggested so networking code later won't have to do the checks on its own, and maybe it can be consistent in the long term. The phonet sockets even needs CAP_SYS_ADMIN... > > They were a mistake, and we should never have done them - another case > of security people who think that complexity == security, when in > reality nobody actually wants the complexity or is willing to set it > up and manage it. Alright, but I guess we are stuck, is there something better on how we can do this or describe this ? Please note in these patches, the mode is specifically described as: * allowed: for backward compatibility (I would have done without it) * privileged: which includes capabilities (backward compatibility too) or we can add what ever in the future * disabled: even for privileged. So I would have preferred if it is something like "yes/no" but... However in userspace we will try hard to hide this complexity and the capability bits. Now I can see that the code comments and doc refer to privileged with capabilities a lot, where we can maybe update that doc and code to less state that privileged means capabilities ? Suggestions ? 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:41:31 +0100 Subject: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules In-Reply-To: References: <1511803118-2552-1-git-send-email-tixxdz@gmail.com> <1511803118-2552-6-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 7:44 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capability and the 'netdev' module prefix to the >> capability subsystem as it was suggested. > > This is the kind of complexity that I wonder if it's worth it at all. > > Nobody sane actually uses those stupid capability bits. Have you ever > actually seen it used in real life? Yes they are complicated even for developers, and normal users do not understand them, however yes every sandbox and container is exposing them to endusers directly, they are documented! so yes CAP_SYS_MODULE is exposed but it does not cover autoloading. However, we are trying hard to abstract some semantics that are easy to grasp, we are mutating capabilities and seccomp to have an abstracted "yes/no" options for our endusers. Now, if you are referring to kernel code, the networking subsystem is using them and I don't want to break any assumption here. There is still the request_module(), the request_module_cap() was suggested so networking code later won't have to do the checks on its own, and maybe it can be consistent in the long term. The phonet sockets even needs CAP_SYS_ADMIN... > > They were a mistake, and we should never have done them - another case > of security people who think that complexity == security, when in > reality nobody actually wants the complexity or is willing to set it > up and manage it. Alright, but I guess we are stuck, is there something better on how we can do this or describe this ? Please note in these patches, the mode is specifically described as: * allowed: for backward compatibility (I would have done without it) * privileged: which includes capabilities (backward compatibility too) or we can add what ever in the future * disabled: even for privileged. So I would have preferred if it is something like "yes/no" but... However in userspace we will try hard to hide this complexity and the capability bits. Now I can see that the code comments and doc refer to privileged with capabilities a lot, where we can maybe update that doc and code to less state that privileged means capabilities ? Suggestions ? 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> <1511803118-2552-6-git-send-email-tixxdz@gmail.com> From: Djalal Harouni Date: Mon, 27 Nov 2017 22:41:31 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules 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 7:44 PM, Linus Torvalds wrote: > On Mon, Nov 27, 2017 at 9:18 AM, Djalal Harouni wrote: >> This uses the new request_module_cap() facility to directly propagate >> CAP_NET_ADMIN capability and the 'netdev' module prefix to the >> capability subsystem as it was suggested. > > This is the kind of complexity that I wonder if it's worth it at all. > > Nobody sane actually uses those stupid capability bits. Have you ever > actually seen it used in real life? Yes they are complicated even for developers, and normal users do not understand them, however yes every sandbox and container is exposing them to endusers directly, they are documented! so yes CAP_SYS_MODULE is exposed but it does not cover autoloading. However, we are trying hard to abstract some semantics that are easy to grasp, we are mutating capabilities and seccomp to have an abstracted "yes/no" options for our endusers. Now, if you are referring to kernel code, the networking subsystem is using them and I don't want to break any assumption here. There is still the request_module(), the request_module_cap() was suggested so networking code later won't have to do the checks on its own, and maybe it can be consistent in the long term. The phonet sockets even needs CAP_SYS_ADMIN... > > They were a mistake, and we should never have done them - another case > of security people who think that complexity == security, when in > reality nobody actually wants the complexity or is willing to set it > up and manage it. Alright, but I guess we are stuck, is there something better on how we can do this or describe this ? Please note in these patches, the mode is specifically described as: * allowed: for backward compatibility (I would have done without it) * privileged: which includes capabilities (backward compatibility too) or we can add what ever in the future * disabled: even for privileged. So I would have preferred if it is something like "yes/no" but... However in userspace we will try hard to hide this complexity and the capability bits. Now I can see that the code comments and doc refer to privileged with capabilities a lot, where we can maybe update that doc and code to less state that privileged means capabilities ? Suggestions ? Thanks! > Linus -- tixxdz