From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Google-Smtp-Source: ACJfBotWmmdZgcIvgNi+WbX1hFBAQY+vTgBlfEzwamNZf7KQBwPtC8O0t7elAJMgZ0YrogNSq4sp ARC-Seal: i=1; a=rsa-sha256; t=1515405122; cv=none; d=google.com; s=arc-20160816; b=cyVNV/giRpqyKEamJyXLoMUUp852EMxw4t9kr8caEkqWwZS/oenoJuZV5G1+rY5s2y j36a5NFp0O6T4oqBDfmNzna/ePaNtUtUSqax3zrUkmjtp4MyhKv8XE+M/y/ojurfJbSZ MK2kl3D2d8exTCHXfeTWy45PDYhrGNT/cX8/FWJrABOcUCrQZwVky6UqMVDnuf8k45Dg QXmFHrT0eVpHn2RFLZQqHyJ3226iT/mwJHYGXE8+q8IJcciuuca9PeSscp4phL09yQEp zgEY31lWdgw0Q9pfngYIVcKpXrUG9/vfmwIUa2C6cc7WpBSBvKXPWKD1IqnLCzWO/4kx kYtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=subject:mime-version:user-agent:references:message-id:in-reply-to :cc:to:from:date:dkim-signature:delivered-to:list-id:list-subscribe :list-unsubscribe:list-help:list-post:precedence:mailing-list :arc-authentication-results; bh=7/8VUx+HsWM+MFIJQ3gjK5Aar/LhlBa0DE5HkwDoehU=; b=DbZy3Oa6BBIFZ37YXAc+cn2Wk/Y2TFTukXOwD8EM7+7FqiD8c0jrS8+h24t+7b839t qp6yKtq8Qa2PsnxF7deCgMok2wcw9Zcu6J4pR5TKwZHZ55pt7f1HXz/Py0KP/4gyrBFC d+z/Q+UXb6A1x/xcbL8vlGzM466N9+kxGOQ755VNI9tk3bB1lYGZhB6IS60Xs5mSSeOO cvSH0dVNIJc2BSWJyi3FKwNAfE7Oq56z+nrpQ5Z0lTQj2sGENd7nQhMbubK7A3AQmWxP 6IkZBVyS2aBP8TzpFSHbB6PF+t2u6VbXUWk7kCxAONAs4EmlAWhPR7GGMqxcLINdFBpd bYIA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@oracle.com header.s=corp-2017-10-26 header.b=LVxdGDHG; spf=pass (google.com: domain of kernel-hardening-return-11086-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11086-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Authentication-Results: mx.google.com; dkim=fail header.i=@oracle.com header.s=corp-2017-10-26 header.b=LVxdGDHG; spf=pass (google.com: domain of kernel-hardening-return-11086-gregkh=linuxfoundation.org@lists.openwall.com designates 195.42.179.200 as permitted sender) smtp.mailfrom=kernel-hardening-return-11086-gregkh=linuxfoundation.org@lists.openwall.com; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=oracle.com Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: Date: Mon, 8 Jan 2018 20:51:20 +1100 (AEDT) From: James Morris X-X-Sender: james.l.morris@localhost To: "Serge E. Hallyn" cc: =?UTF-8?Q?Mahesh_Bandewar_=28=E0=A4=AE=E0=A4=B9=E0=A5=87=E0=A4=B6_=E0=A4=AC=E0=A4=82=E0=A4=A1=E0=A5=87=E0=A4=B5=E0=A4=BE=E0=A4=B0=29?= , LKML , Netdev , Kernel-hardening , Linux API , Kees Cook , "Eric W . Biederman" , Eric Dumazet , David Miller , Mahesh Bandewar In-Reply-To: <20180108062452.GA21717@mail.hallyn.com> Message-ID: References: <20171205223052.12687-1-mahesh@bandewar.net> <20180108062452.GA21717@mail.hallyn.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8767 signatures=668652 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=865 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801080144 Subject: [kernel-hardening] Re: [PATCHv3 0/2] capability controlled user-namespaces X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: =?utf-8?q?1585984920411073844?= X-GMAIL-MSGID: =?utf-8?q?1589017441555866387?= X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On Mon, 8 Jan 2018, Serge E. Hallyn wrote: > > Also, why do we need the concept of a controlled user-ns at all, if the > > default whitelist maintains existing behavior? > > In past discussions two uses have been brought up: > > 1. if an 0-day is discovered which is exacerbated by a specific > privilege in user namespaces, that privilege could be turned off until a > reboot with a fixed kernel is scheduled, without fully disabling all > containers. > > 2. some systems may be specifically designed to run software which > only requires a few capabilities in a userns. In that case all others > could be disabled. > I meant in terms of "marking" a user ns as "controlled" type -- it's unnecessary jargon from an end user point of view. This may happen internally but don't make it a special case with a different name and don't bother users with internal concepts: simply implement capability whitelists with the default having equivalent behavior of everything allowed. Then, document the semantics of the whitelist in terms of inheritance etc., as a feature of user namespaces, not as a "type" of user namespace. - James -- James Morris