Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp34165pxb; Wed, 20 Jan 2021 00:03:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwz2d6c5Vo1cPFffgqSJRKLMlwgwXNxVewubzyjgSC94GinDhjtyXTygPky5flPlqhIvvHG X-Received: by 2002:aa7:d9c3:: with SMTP id v3mr6213692eds.133.1611129825513; Wed, 20 Jan 2021 00:03:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611129825; cv=none; d=google.com; s=arc-20160816; b=QS2NwCr0X+zceaj+UBFtGiUlLCeF/1B5Ud8Mgw3IFepa8WcquRzJYk0IdfqclVTaML oR5aplXnxC33AwVd0OmrzThYJ6488WQLnjT/Gu3oJdiWexXXtkwv8XyJz9xrwv+TO1jZ LVVSG6Al2uiM7KOxnrGhYGOB6oVQVR6ZYfBKq8c/DXR3ReudHChoLQ7gqMlugGfEUSFm r9B5TF9RQp33e52x5y8ZwVIYSLq0F6DmOqSrc5G8vyf3g1OMEFkqEB47laCK/SEXLO0f F91bMmsEon6lhUd3ee1NvAbRmzA62UQl8Rk1oeTAOcTBQX6aB9BzQ0SfxlnZupvBOUG5 UYkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=raG85U5m6BVpkFn9tnlYSwbmBuD+wqMz8bt05EHQnpE=; b=A7bzkwAImxH5L9FTdhNtwB0fLo9I36L5ysX0zm0qwZyGsA/7x9pwOEU0t5ieZqxLk5 DkS2wPQgdYoXZC1T5FYLjrVQUZISxABl4yN0El8xot9K3PEfgLU9Zz1pfISkZNgjTT2l BNmJuG678pl+uaGQ+jXb4LgpABkzvhqaHGErnPnQLGFkVGq8f5t5TyDAuaAExuw7Kxnt w1wAz0lqmvfsf6d1pWL89cyPrGVm+jCRtADhiN2WAg/0Z/Lp0cqerpWZBtoWZIZQgsoL Ba25MAtiYpsIOpV7k3lYcQkJaLK1xxvvyyWFbZwx6ZZOE2+pVooTPL5y1+oJ4XCSpeJm bzUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=COBq+q3D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p22si540468edt.391.2021.01.20.00.03.21; Wed, 20 Jan 2021 00:03:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=temperror (no key for signature) header.i=@szeredi.hu header.s=google header.b=COBq+q3D; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729911AbhATIBv (ORCPT + 99 others); Wed, 20 Jan 2021 03:01:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730243AbhATH7p (ORCPT ); Wed, 20 Jan 2021 02:59:45 -0500 Received: from mail-vk1-xa29.google.com (mail-vk1-xa29.google.com [IPv6:2607:f8b0:4864:20::a29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C14CC0613C1 for ; Tue, 19 Jan 2021 23:59:05 -0800 (PST) Received: by mail-vk1-xa29.google.com with SMTP id v3so5465574vkb.1 for ; Tue, 19 Jan 2021 23:59:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=szeredi.hu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=raG85U5m6BVpkFn9tnlYSwbmBuD+wqMz8bt05EHQnpE=; b=COBq+q3DyHX/wjdBbdPiY06GVMPcsbaUsOQZTyJ7qWCOT9Qwlsa14PlxON1EmmP3dn ZyLBJZlg9mscFGi0pxRYe1PkgnxzZ7cc4PGSDkCygYvQXkYEPB+iqlRQKVsFYRij4TSP 0se7PqcCswNtOkSxGRxAGUJHRKavvDfakuICQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=raG85U5m6BVpkFn9tnlYSwbmBuD+wqMz8bt05EHQnpE=; b=Nsx5lKA5j0hc/nCMpJZg7H3JvvqiMxtfAdG9a6ktJdb7LeU1y3vIuzbx0+HsTgeHyS 0Hd6ts+QEnHgevSAgGeXp4Q2DIPDyyl5IKEK/DXOODag6qPYopSTwwoh8NPluO9ve+tU 4F6F/fKN3mOQqBzGkWysZOqlaFFfzIsheLi0duNqjcF9gEYTf5H/uUrORHMiCnDH86jA +j11IBa9MCBKhj1BTpilvhYgNfL8DgWnYSZYP8Lze0VbsBt/6WSxFJ0cIEOQLG9BJKNn ztT5wSuEdWbqccGBZpEKTP+epfZ87cx9v/X6OwqUT/kRTFFDMJGNX9KowpKX6ySsZkEp Ot2w== X-Gm-Message-State: AOAM530Qg8PUcIEUENdTV+O/0ZXniNEIDy4MNvt7+I6dFGGcHAGuEEuc zTsjFu0koxhFiiFy0aJ0RpKGLVyfbS8ZpiV2aMVDcw== X-Received: by 2002:a1f:410c:: with SMTP id o12mr5782747vka.19.1611129544253; Tue, 19 Jan 2021 23:59:04 -0800 (PST) MIME-Version: 1.0 References: <20210119162204.2081137-1-mszeredi@redhat.com> <20210119162204.2081137-3-mszeredi@redhat.com> <8735yw8k7a.fsf@x220.int.ebiederm.org> In-Reply-To: <8735yw8k7a.fsf@x220.int.ebiederm.org> From: Miklos Szeredi Date: Wed, 20 Jan 2021 08:58:53 +0100 Message-ID: Subject: Re: [PATCH 2/2] security.capability: fix conversions on getxattr To: "Eric W. Biederman" Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org, overlayfs , LSM , linux-kernel@vger.kernel.org, "Serge E . Hallyn" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 20, 2021 at 2:39 AM Eric W. Biederman wrote: > > Miklos Szeredi writes: > > > If a capability is stored on disk in v2 format cap_inode_getsecurity() will > > currently return in v2 format unconditionally. > > > > This is wrong: v2 cap should be equivalent to a v3 cap with zero rootid, > > and so the same conversions performed on it. > > > > If the rootid cannot be mapped v3 is returned unconverted. Fix this so > > that both v2 and v3 return -EOVERFLOW if the rootid (or the owner of the fs > > user namespace in case of v2) cannot be mapped in the current user > > namespace. > > This looks like a good cleanup. > > I do wonder how well this works with stacking. In particular > ovl_xattr_set appears to call vfs_getxattr without overriding the creds. > What the purpose of that is I haven't quite figured out. It looks like > it is just a probe to see if an xattr is present so maybe it is ok. Yeah, it's checking in the removexattr case whether copy-up is needed or not (i.e. if trying to remove a non-existent xattr, then no need to copy up). But for consistency it should also be wrapped in override creds. Adding fix to this series. I'll also audit for any remaining omissions. One known and documented case is vfs_ioctl(FS_IOC_{[SG]ETFLAGS,FS[SG]ETXATTR}), but that shouldn't be affected by user namespaces. Thanks, Miklos