linux-kernel - Re: [PATCH] CRED: Fix check_unsafe

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] [day] [month] [year] [list]

Date:	Mon, 16 Mar 2009 22:15:23 +0000 (GMT)
From:	Hugh Dickins <hugh@...itas.com>
To:	David Howells <dhowells@...hat.com>
cc:	jmalicki@...acarta.com, chrisw@...s-sol.org,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH] CRED: Fix check_unsafe_exec()

On Thu, 12 Mar 2009, David Howells wrote:
> Hugh Dickins <hugh@...itas.com> wrote:
> 
> > We do.  See the original thread.  It's here at
> > http://lkml.org/lkml/2009/2/26/233
> > and appended below for convenience.  We do know that patch did not
> > fix Joe's problem, and we don't yet know whether addressing the
> > files->count issue will actually fix it, but I'm hopeful.
> 
> Looks reasonable.

Thanks for taking a look.

Yes, I'm inclined to go with that, and removing the files->count
check from exec.c.  Joe, did you manage to try your testing with
my original patch plus that files->count check removed from 2.6.28's
unsafe_exec()?

Though I've since thought a better answer would probably be to unshare
fs and sighand from the exec'ing task in the same way that files is
unshared at the start, then I hope we wouldn't need to suppress setuid
in the case when any of those had been shared.

But I believe that course would make a slight difference to the behaviour
of the respective CLONE flags versus exec: I'd guess a difference that
nobody cares about, but my guesses don't count for much here, and I
really don't want to cause any regression.

Chris, have you had a chance to look at any of this yet?

> One thing that should be added, though, is a comment in
> struct fs_struct to give a warning about the consequences of incrementing the
> usage count for anything other than CLONE_FS.

Yes, that's a very sensible addition, thanks - if we do go this way,
rather than unsharing.  I'll hold on to this as one of a set of three:
my original fs->count avoidance one, your comment on that below, and
removing the files->count check from exec.c.

Since Joe's bug has been around forever (if it is what we think it
is), I'm disinclined to rush the fix - something nice to add to
-stable, rather than needing to squeeze into 2.6.29.

Hugh

> 
> David
> ---
> From: David Howells <dhowells@...hat.com>
> Subject: [PATCH] Annotate struct fs_struct's usage count to indicate the restrictions upon it
> 
> Annotate struct fs_struct's usage count to indicate the restrictions upon it.
> It may not be incremented, except by clone(CLONE_FS), as this affects the
> check in check_unsafe_exec() in fs/exec.c.
> 
> Signed-off-by: David Howells <dhowells@...hat.com>
> ---
> 
>  include/linux/fs_struct.h |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> 
> diff --git a/include/linux/fs_struct.h b/include/linux/fs_struct.h
> index a97c053..b12ede4 100644
> --- a/include/linux/fs_struct.h
> +++ b/include/linux/fs_struct.h
> @@ -4,7 +4,11 @@
>  #include <linux/path.h>
>  
>  struct fs_struct {
> -	atomic_t count;
> +	atomic_t count;	/* This usage count is used by check_unsafe_exec() for
> +			 * security checking purposes - therefore it may not be
> +			 * incremented, except by clone(CLONE_FS).
> +			 */
> +
>  	rwlock_t lock;
>  	int umask;
>  	struct path root, pwd;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/