On Mon, 2012-12-31 at 14:14 +0400, Andrew Vagin wrote: > On Sun, Dec 30, 2012 at 05:03:07PM -0500, Eric Paris wrote: > > On Sat, 2012-12-29 at 15:00 +0400, Andrey Vagin wrote: > > > The address should be bigger than dac_mmap_min_addr, because > > > a process with CAP_RAWIO can map a vma bellow mmap_min_addr. > > > > NAK > > Currently prctl(PR_SET_MM_*, addr, ) returns EINVAL for valid addresses. > I think it's a bug. Are you agree?
Can you help me understand how prctl(PR_SET_MM_*, relates to checkpoint/restore? My worry here is that somehow this interface could be used to bypass the security properties of mmap_min_addr. I have no idea how the interface is used, so I don't know if my fears are founded. When I hear 'restore' I think of a privileged application setting up some unprivileged application based on untrusted data. My fear is that some unpriv application, that doesn't have permission to map below mmap_min_addr, may be able to trick the privileged application, which would have this permission, into doing it on its behalf. Does that make sense? Is that a realistic scenario with how this interface is used? > CONFIG_LSM_MMAP_MIN_ADDR could not be got from user space. > > This application can use a real value of mmap_min_addr, but it is not > provided into userspace. Unrelated to this patch issue, but I guess either could be exposed if there is a need. > Currently a task can have user memory area bellow dac_mmap_min_addr, > but prctl returns -EINVAL for such addresses. > How can I understand the reason, if I know that the address is valid? Talking about dac_mmap_min_addr is wrong. The capabilities security module uses dac_mmap_min_addr but other LSMs can (and obviously do) use other things. mmap_min_addr is just the shorthand to make sure you clear all hurdles. Breaking those hurdles up outside of the security subsystem is wrong. The kernel makes the decision on what is valid via security_mmap_addr(). Assuming there are no security fears of an untrusted application tricking some priviledged application to set up these maps the answer is just calling security_mmap_addr() instead of doing if(addr < mmap_min_addr) return -EINVAL; I don't know if it is a good idea to allow this interface to ever go below mmap_min_addr, but I do know that using (or even thinking about) dac_mmap_min_addr is wrong and you should be looking at security_mmap_addr() if you look at anything... -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
