Re: ima_mmap_file returning 0 to userspace as mmap result.

[Dave Jones]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/