Kees Cook <keesc...@chromium.org> writes: > On Wed, Aug 28, 2013 at 6:08 PM, Eric W. Biederman > <ebied...@xmission.com> wrote: >> Kees Cook <keesc...@chromium.org> writes: >> >>> On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman >>> <ebied...@xmission.com> 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?
As in any checks at open time are insufficient. Roughly what we need is to use the credentials that are present at open time (file->f_cred) in the ptrace_may_access call instead of or in addition to current_cred(). 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/
