On Wed, Aug 28, 2013 at 6:08 PM, Eric W. Biederman <[email protected]> wrote: > Kees Cook <[email protected]> writes: > >> On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman >> <[email protected]> wrote: >>> Can someome please state what they are worried about in simple language >>> step by step? >>> [...] >>> The closest I saw in the thread was people were worried about ASLR being >>> defeated. All I see are kernel addresses and we don't have much if any >>> runtime or even load time randomization of where code is located in the >>> kernel address map on x86_64. So I don't understand the concern. >> >> I showed the output of "syscall", since that contains user-space >> addresses and shows a leak of ASLR from a privileged process to an >> unprivileged process. >> >> The flaw as I see it is that an unprivileged process opens >> /proc/$priv_pid/syscall and passes it to a setuid process which is >> able to read it, and provides those contents to the unprivileged >> process. >> >> The unprivileged process should not be able to the open the file in >> the first place. > > I see so the complaint is that we don't give read permission but we do > give open permission. Which is a variant of: the permissions used to > open are not the permission used to access the file. > > This does seem to be a legitimate concern. > > I think there are several discussions that have been going on lately > with respect to this class of problems in proc files. > > Given the existence of suid exec we can not in general prevent this > class of bugs with a check at open time.
I'm not suggesting removing the read check -- that's certainly needed. > I believe the solution needs to be to enhance the ptrace_may_access > checks to verify that both the creds of the current task and the creds > of the opening process would have allowed the access. As in, DAC perms are insufficient? > We may want to put this check in permission so open fails quickly but > we absolutely need to put this check in at the time we call > ptrace_may_access. -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
