From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754960AbcEBScF (ORCPT ); Mon, 2 May 2016 14:32:05 -0400 Received: from mail-wm0-f47.google.com ([74.125.82.47]:37043 "EHLO mail-wm0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754766AbcEBSbs (ORCPT ); Mon, 2 May 2016 14:31:48 -0400 Subject: Re: [PATCH 1/1] simplified security.nscapability xattr To: "Serge E. Hallyn" , Kees Cook References: <1461345993-17526-1-git-send-email-serge.hallyn@ubuntu.com> <1461345993-17526-2-git-send-email-serge.hallyn@ubuntu.com> <20160426222627.GA19307@mail.hallyn.com> <20160502035452.GA31837@mail.hallyn.com> Cc: mtk.manpages@gmail.com, "Eric W. Biederman" , Jann Horn , "Serge E. Hallyn" , Linux API , Linux Containers , LKML , Andy Lutomirski , "Andrew G. Morgan" From: "Michael Kerrisk (man-pages)" Message-ID: <1dfc8e3c-0c8c-0b85-df6f-960442b63a1e@gmail.com> Date: Mon, 2 May 2016 20:31:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160502035452.GA31837@mail.hallyn.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/02/2016 05:54 AM, Serge E. Hallyn wrote: > On Tue, Apr 26, 2016 at 03:39:54PM -0700, Kees Cook wrote: >> On Tue, Apr 26, 2016 at 3:26 PM, Serge E. Hallyn wrote: >>> Quoting Kees Cook (keescook@chromium.org): >>>> On Fri, Apr 22, 2016 at 10:26 AM, wrote: >>>>> From: Serge Hallyn > ... >>>> This looks like userspace must knowingly be aware that it is in a >>>> namespace and to DTRT instead of it being translated by the kernel >>>> when setxattr is called under !init_user_ns? >>> >>> Yes - my libcap2 patch checks /proc/self/uid_map to decide that. If that >>> shows you are in init_user_ns then it uses security.capability, otherwise >>> it uses security.nscapability. >>> >>> I've occasionally considered having the xattr code do the quiet >>> substitution if need be. >>> >>> In fact, much of this structure comes from when I was still trying to >>> do multiple values per xattr. Given what we're doing here, we could >>> keep the xattr contents exactly the same, just changing the name. >>> So userspace could just get and set security.capability; if you are >>> in a non-init user_ns, if security.capability is set then you cannot >>> set it; if security.capability is not set, then the kernel writes >>> security.nscapability instead and returns success. >>> >>> I don't like magic, but this might be just straightforward enough >>> to not be offensive. Thoughts? >> >> Yeah, I think it might be better to have the magic in this case, since >> it seems weird to just reject setxattr if a tool didn't realize it was >> in a namespace. I'm not sure -- it is also nice to have an explicit >> API here. >> >> I would defer to Eric or Michael on that. I keep going back and forth, >> though I suspect it's probably best to do what you already have >> (explicit API). > > Michael, Eric, what do you think? The choice we're making here is > whether we should > > 1. Keep a nice simple separate pair of xattrs, the pre-existing > security.capability which can only be written from init_user_ns, > and the new (in this patch) security.nscapability which you can > write to any file where you are privileged wrt the file. > > 2. Make security.capability somewhat 'magic' - if someone in a > non-initial user ns tries to write it and has privilege wrt the > file, then the kernel silently writes security.nscapability instead. > > The biggest drawback of (1) would be any tar-like program trying > to restore a file which had security.capability, needing to know > to detect its userns and write the security.nscapability instead. > The drawback of (2) is ~\o/~ magic. I have only (minor) thoughts from the interface perspective. (1) Sounds the source of possibly unpleasant surprises. (2) Is a little surprising, but less so if it's well documented, and it saves us the surprises of (1). So, (2) sounds better. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/