From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965882AbbJVVzM (ORCPT ); Thu, 22 Oct 2015 17:55:12 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:53907 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964902AbbJVVzI (ORCPT ); Thu, 22 Oct 2015 17:55:08 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Andy Lutomirski Cc: Tobias Markus , "Serge E. Hallyn" , "linux-kernel\@vger.kernel.org" , Al Viro , Serge Hallyn , Andrew Morton , Christoph Lameter , "Michael Kerrisk \(man-pages\)" , LSM List , Linux API , linux-man , Richard Weinberger , Yves-Alexis Perez , Austin S Hemmelgarn , Linux Containers References: <5622700C.9090107@miglix.eu> <20151017215501.GA22900@mail.hallyn.com> <5623FD82.4030902@miglix.eu> <87twpi63ai.fsf@x220.int.ebiederm.org> Date: Thu, 22 Oct 2015 16:44:49 -0500 In-Reply-To: (Andy Lutomirski's message of "Thu, 22 Oct 2015 14:02:09 -0700") Message-ID: <874mhi4lym.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX19J5vzHxZuuL6a8ZPX90CVWMmGEI2TC2BY= X-SA-Exim-Connect-IP: 67.3.201.231 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Andy Lutomirski X-Spam-Relay-Country: X-Spam-Timing: total 1484 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 4.0 (0.3%), b_tie_ro: 2.9 (0.2%), parse: 0.97 (0.1%), extract_message_metadata: 14 (0.9%), get_uri_detail_list: 1.91 (0.1%), tests_pri_-1000: 5 (0.4%), tests_pri_-950: 1.20 (0.1%), tests_pri_-900: 1.04 (0.1%), tests_pri_-400: 24 (1.6%), check_bayes: 23 (1.5%), b_tokenize: 7 (0.5%), b_tok_get_all: 7 (0.5%), b_comp_prob: 2.7 (0.2%), b_tok_touch_all: 3.2 (0.2%), b_finish: 0.78 (0.1%), tests_pri_0: 1425 (96.0%), tests_pri_500: 6 (0.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH] userns/capability: Add user namespace capability X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 24 Sep 2014 11:00:52 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andy Lutomirski writes: > At the risk of pointing out a can of worms, the attack surface also > includes things like the iptables configuration APIs, parsers, and > filter/conntrack/action modules. It is worth noting that module auto-load does not happen if the triggering code does not have the proper permissions in the initial user namespace. I agree that is another piece of code that should be counted. How that compares to the other 130,000 or so lines of code in the network stack an unprivileged user can caused to be exercised already I don't know. In my back of the napkin swag I had totally forgotten to count anything in the network stack. A lot of the netfilter code that I have read and looked at is compartively simple and clean so I don't expect there is much risk except from sheer volume of code there. It is also tricky to count because the entire network side of the networking stack is exposed to hostile users on the internet so anything except the configuration is already exposed to hostile users. The average check entry is 15-20 lines long. There appear to be 117 unique check entry functions in the kernel so there may be another 2.5k lines of code there. Hmm. And we have not had any design issues with the network stack. Absent of design issues where the code even when implemented correctly has the wrong semantics, we are left with the probability of exploitable buggy code. I suspect we have enough code even without user namespaces enabled that the probability of exploitable buggy code someone in the code that unprivilged users can cause to be exercised run is > 50%. I wonder if there are any good statistical models that give realistic estimates of those things. Eric