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]
Date:	Mon, 25 Jul 2016 22:22:42 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	Stanislav Kinsburskiy <skinsbursky@...tuozzo.com>,
	peterz@...radead.org, mingo@...hat.com, mhocko@...e.com,
	keescook@...omium.org, linux-kernel@...r.kernel.org,
	mguzik@...hat.com, bsegall@...gle.com, john.stultz@...aro.org,
	oleg@...hat.com, matthltc@...ibm.com, akpm@...ux-foundation.org,
	luto@...capital.net, vbabka@...e.cz, xemul@...tuozzo.com
Subject: Re: [PATCH] prctl: remove one-shot limitation for changing exe link

On Mon, Jul 25, 2016 at 01:21:51PM -0500, Eric W. Biederman wrote:
> Stanislav Kinsburskiy <skinsbursky@...tuozzo.com> writes:
> 
> > Gentlemen,
> >
> > Looks like there are no objections to this patch.
> 
> There has been objection.
> 
> The only justification for the change that has been put forward is
> someone doing a restore lazily.  I don't see a reason why you can't call
> prctl_set_mm_exe_file until you have the file in place instead of a
> place holder that sounds like a trivial solution to any restore issues.
> 
> The truth is an unlimited settable exe link is essentially meaningless,
> as you can't depend on it for anything.  One shot seems the best
> compromise I have seen put forward between the definite
> checkpoint/restart requirement to set the this value and the general
> need to have something that makes sense and people can depend on for
> system management.
>
> Also there is a big fat bug in prctl_set_mm_exe_file.  It doesn't
> validate that the new file is a actually mmaped executable.  We would
> definitely need that to be fixed before even considering removing the
> limit.

Could you please elaborate? We check for inode being executable,
what else needed?

> Right now all I see is people involved in the implementation details of
> their own little feature
> 
> So for the patch I am responding to:
> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
> 
> Plus the merge window is open so no one is taking any patches right now.
> It is the time to take what has already been staged and get that code
> merged.
> 
> Eric
> 

	Cyrill

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ