linux-kernel - Re: [PATCH 2/5] security,overlayfs: Provide security hook for copy up of xattrs for overlay file

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: <20160705215313.GJ17987@redhat.com>
Date:	Tue, 5 Jul 2016 17:53:13 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Paul Moore <pmoore@...hat.com>
Cc:	miklos@...redi.hu, sds@...ho.nsa.gov, linux-kernel@...r.kernel.org,
	linux-unionfs@...r.kernel.org,
	linux-security-module@...r.kernel.org, dwalsh@...hat.com,
	dhowells@...hat.com, viro@...iv.linux.org.uk,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 2/5] security,overlayfs: Provide security hook for copy
 up of xattrs for overlay file

On Tue, Jul 05, 2016 at 05:45:25PM -0400, Paul Moore wrote:
> On Tue, Jul 5, 2016 at 11:50 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> > Provide a security hook which is called when xattrs of a file are being
> > copied up. This hook is called once for each xattr and one can either
> > accept or reject xattr. If 0 is returned, xattr will be copied up, if 1
> > is returned, xattr will not be copied up and if negative error code
> > is returned, copy up will be aborted.
> >
> > In SELinux, label of lower file is not copied up. File already has been
> > set with right label at the time of creation and we don't want to overwrite
> > that label.
> >
> > Signed-off-by: David Howells <dhowells@...hat.com>
> > Signed-off-by: Vivek Goyal <vgoyal@...hat.com>
> > ---
> >  fs/overlayfs/copy_up.c    |  8 ++++++++
> >  include/linux/lsm_hooks.h | 13 +++++++++++++
> >  include/linux/security.h  | 10 ++++++++++
> >  security/security.c       |  9 +++++++++
> >  security/selinux/hooks.c  | 14 ++++++++++++++
> >  5 files changed, 54 insertions(+)
> 
> To continue the earlier feedback about mixing generic LSM hook
> definitions with the SELinux specific hook implementations - I prefer
> to see patchsets organized in the following manner:
> 
> [PATCH 1/X] - add new LSM hooks and the calls from the relevant
> subsystems, e.g.
> {security/security.c,include/linux/security.h,fs/overlayfs/*}
> [PATCH 2/X] - LSM specific hook implementation, e.g. security/selinux/*
> [PATCH n/X] - LSM specific hook implementation, e.g. security/smack/*

Ok, will do this way.

Vivek