linux-kernel - Re: [PATCH 1/5] security: allow finer granularity in permitting copy-up of security xattrs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240201-zierpflanzen-allgegenwart-5eb1fa243a61@brauner>
Date: Thu, 1 Feb 2024 14:35:39 +0100
From: Christian Brauner <brauner@...nel.org>
To: Stefan Berger <stefanb@...ux.ibm.com>
Cc: Amir Goldstein <amir73il@...il.com>, linux-integrity@...r.kernel.org, 
	linux-security-module@...r.kernel.org, linux-unionfs@...r.kernel.org, linux-kernel@...r.kernel.org, 
	paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com, zohar@...ux.ibm.com, 
	roberto.sassu@...wei.com, miklos@...redi.hu
Subject: Re: [PATCH 1/5] security: allow finer granularity in permitting
 copy-up of security xattrs

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 PM Stefan Berger <stefanb@...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 content as
> > > > well.
> > > > 
> > > > Signed-off-by: Stefan Berger <stefanb@...ux.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, const struct path *oldpath, struct de
> > > >                  if (ovl_is_private_xattr(sb, name))
> > > >                          continue;
> > > > 
> > > > -               error = security_inode_copy_up_xattr(name);
> > > > +               error = security_inode_copy_up_xattr(old, name);
> > > 
> > > What do you think about:
> > > 
> > >                       error = security_inode_copy_up_xattr(name, NULL, 0);
> > > 
> > > and then later...
> > > 
> > >                       error = 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?