Messages in this thread | | | Date | Wed, 28 Aug 2013 20:33:20 -0700 | Subject | Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality} | From | Kees Cook <> |
| |
On Wed, Aug 28, 2013 at 6:08 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Kees Cook <keescook@chromium.org> writes: > >> On Wed, Aug 28, 2013 at 5:26 PM, Eric W. Biederman >> <ebiederm@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?
> 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
| |