On Thu, Apr 18, 2019 at 02:23:26AM -0500, Kees Cook wrote: > On Thu, Apr 18, 2019 at 2:01 AM Jason Gunthorpe <jgg@xxxxxxxx> wrote: > > > > On Thu, Apr 18, 2019 at 01:30:07AM -0500, Kees Cook wrote: > > > > > Anything running with READ_IMPLIES_EXEC (i.e. a gnu stack marked WITH > > > execute) should be considered broken. Now, the trouble is that this > > > personality flag is carried across execve(), so if you have a launcher > > > that doesn't fix up the personality for children, you'll see this > > > spread all over your process tree. What is doing rdma mmap calls with > > > an executable stack? That really feels to me like the real source of > > > the problem. > > > > Apparently the Fortran runtime forces the READ_IMPLIES_EXEC and > > requires it for some real reason or another - Fortran and RDMA go > > together in alot of cases. > > That's pretty unfortunate for the security of the resulting proceses. :( I think it probably arises from a need for exec stacks in the runtime... That Linux escalates that to full READ_IMPLIES_EXEC seems quite unfortunate. Hopefully your patch will get accepted as it makes a lot of sense. > I wonder if we could simply make devtmpfs ignore READ_IMPLIES_EXEC > entirely, though? And I wonder if we could defang READ_IMPLIES_EXEC a > bit in general. It was _supposed_ to be for the cases where binaries > were missing exec bits and a processor was just gaining NX ability. I > know this has been discussed before... ah-ha, here it is: > http://lkml.kernel.org/r/1462963502-11636-1-git-send-email-hecmargi@xxxxxx Globally banning VM_EXEC from char device nodes also sounds very appealing to me (particularly from a W^X sense)... There are not very many grep hits on VM_EXEC in drivers/*, and none of the ones I looked at seemed problematic. Jason
