[kernel-hardening] Re: [PATCH 1/2] procfs: restore 0400 permissions on /proc/*/{syscall,stack,personality}

[ebiederm@xmission.com (Eric W. Biederman)]

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 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.

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.

Eric