linux-kernel - Re: ima_mmap_file returning 0 to userspace as mmap result.

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:	Thu, 5 Jun 2014 11:56:58 -0400
From:	Dave Jones <davej@...hat.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>, linux-mm@...ck.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	zohar@...ux.vnet.ibm.com
Subject: Re: ima_mmap_file returning 0 to userspace as mmap result.

On Thu, Jun 05, 2014 at 06:40:36AM +0200, Michael Kerrisk (man-pages) wrote:
 > On 06/05/2014 01:31 AM, Dave Jones wrote:
 > > I just noticed that trinity was freaking out in places when mmap was
 > > returning zero.  This surprised me, because I had the mmap_min_addr
 > > sysctl set to 64k, so it wasn't a MAP_FIXED mapping that did it.
 > > 
 > > There's no mention of this return value in the man page, so I dug
 > > into the kernel code, and it appears that we do..
 > > 
 > > sys_mmap
 > > vm_mmap_pgoff
 > > security_mmap_file
 > > ima_file_mmap <- returns 0 if not PROT_EXEC
 > > 
 > > and then the 0 gets propagated up as a retval all the way to userspace.
 > > 
 > > It smells to me like we might be violating a standard or two here, and
 > > instead of 0 ima should be returning -Esomething
 > > 
 > > thoughts?
 > 
 > Seems like either EACCESS or ENOTSUP is appropriate; here's the pieces 
 > from POSIX:
 > 
 >        EACCES The  fildes argument is not open for read, regardless of
 >               the protection specified, or  fildes  is  not  open  for
 >               write and PROT_WRITE was specified for a MAP_SHARED type
 >               mapping.
 > 
 >        ENOTSUP
 >                    The implementation does not support the combination
 >                    of accesses requested in the prot argument.
 > 
 > ENOTSUP seems to be more appropriate in my reading of the above, though
 > I'd somehow more have expected EACCES.

I just realised that this affects even kernels with CONFIG_IMA unset,
because there we just do 'return 0' unconditionally.

Also, it appears that kernels with CONFIG_SECURITY unset will also
return a zero for the same reason.

This is kind of a mess, and has been that way for a long time.
Fixing this will require user-visible breakage, but in this case
I think it's justified as there's no way an app can do the right thing
if it gets a 0 back.  Linus ?

	Dave

--
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/