Received-SPF: pass (google.com: domain of linux-kernel+bounces-48302-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240130214620.3155380-1-stefanb@linux.ibm.com>
 <20240130214620.3155380-2-stefanb@linux.ibm.com> <CAOQ4uxjgdvGU0WE+92ByQE26Jp0j16AgfyCjNyEp7=86akOSsA@mail.gmail.com>
 <20240131-lacht-elend-536d94682370@brauner> <05fe58a1-9b2c-4c1f-80a6-4cb5094a2126@linux.ibm.com>
 <20240201-zierpflanzen-allgegenwart-5eb1fa243a61@brauner>
In-Reply-To: <20240201-zierpflanzen-allgegenwart-5eb1fa243a61@brauner>
From: Amir Goldstein <amir73il@gmail.com>
Date: Thu, 1 Feb 2024 16:18:32 +0200
Message-ID: <CAOQ4uxgfkdX+3VR9sA7SeB7f3BW89iAwF2-JRCcJNsurtune_g@mail.gmail.com>
Subject: Re: [PATCH 1/5] security: allow finer granularity in permitting
 copy-up of security xattrs
To: Christian Brauner <brauner@kernel.org>
Cc: Stefan Berger <stefanb@linux.ibm.com>, linux-integrity@vger.kernel.org, 
	linux-security-module@vger.kernel.org, linux-unionfs@vger.kernel.org, 
	linux-kernel@vger.kernel.org, paul@paul-moore.com, jmorris@namei.org, 
	serge@hallyn.com, zohar@linux.ibm.com, roberto.sassu@huawei.com, 
	miklos@szeredi.hu
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 1, 2024 at 3:35=E2=80=AFPM Christian Brauner <brauner@kernel.or=
g> wrote:
>
> On Wed, Jan 31, 2024 at 09:56:25AM -0500, Stefan Berger wrote:
> >
> >
> > On 1/31/24 09:25, Christian Brauner wrote:
> > > On Wed, Jan 31, 2024 at 03:25:29PM +0200, Amir Goldstein wrote:
> > > > On Tue, Jan 30, 2024 at 11:46=E2=80=AFPM Stefan Berger <stefanb@lin=
ux.ibm.com> wrote:
> > > > >
> > > > > Copying up xattrs is solely based on the security xattr name. For=
 finer
> > > > > granularity add a dentry parameter to the security_inode_copy_up_=
xattr
> > > > > hook definition, allowing decisions to be based on the xattr cont=
ent as
> > > > > well.
> > > > >
> > > > > Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
> > > > > ---
> > > > >   fs/overlayfs/copy_up.c            | 2 +-
> > > > >   include/linux/evm.h               | 2 +-
> > > > >   include/linux/lsm_hook_defs.h     | 3 ++-
> > > > >   include/linux/security.h          | 4 ++--
> > > > >   security/integrity/evm/evm_main.c | 2 +-
> > > > >   security/security.c               | 7 ++++---
> > > > >   security/selinux/hooks.c          | 2 +-
> > > > >   security/smack/smack_lsm.c        | 2 +-
> > > > >   8 files changed, 13 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/fs/overlayfs/copy_up.c b/fs/overlayfs/copy_up.c
> > > > > index b8e25ca51016..bd9ddcefb7a7 100644
> > > > > --- a/fs/overlayfs/copy_up.c
> > > > > +++ b/fs/overlayfs/copy_up.c
> > > > > @@ -114,7 +114,7 @@ int ovl_copy_xattr(struct super_block *sb, co=
nst struct path *oldpath, struct de
> > > > >                  if (ovl_is_private_xattr(sb, name))
> > > > >                          continue;
> > > > >
> > > > > -               error =3D security_inode_copy_up_xattr(name);
> > > > > +               error =3D security_inode_copy_up_xattr(old, name)=
;
> > > >
> > > > What do you think about:
> > > >
> > > >                       error =3D security_inode_copy_up_xattr(name, =
NULL, 0);
> > > >
> > > > and then later...
> > > >
> > > >                       error =3D security_inode_copy_up_xattr(name, =
value, size);
> > > >
> > > > I am asking because overlayfs uses mnt_idmap(path->mnt) and you
> > > > have used nop_mnt_idmap inside evm hook.
> > > > this does not look right to me?
> > >
> > > So it's relevant if they interact with xattrs that care about the
> > > idmapping and that's POSIX ACLs and fscaps. And only if they perform
> > > permission checks such as posix_acl_update_mode() or something. IOW, =
it
> > > depends on what exactly EVM is doing.
> >
> > In 2/5 we are reading the value of security.evm to look at its contents=
.
>
> I'm not sure what this is supposed to be telling me in relation to the
> original question though. :) security.evm doesn't store any {g,u}id
> information afaict. IOW, it shouldn't matter?

But it does. in evm_calc_hmac_or_hash() =3D> hmac_add_misc():

        hmac_misc.uid =3D from_kuid(&init_user_ns, inode->i_uid);
        hmac_misc.gid =3D from_kgid(&init_user_ns, inode->i_gid);

I guess as far as EVM is concerned, it should always be interested in the
absolute uig/gid values of the inode.

Thanks,
Amir.