grsecurity forums

We noticed that, when PROC_MEMMAP is turned on, the futex code (get_robust_list()) uses ptrace_may_access() instead of doing euid checks, ie.:

Code: Select all

                if (!ptrace_may_access(p, PTRACE_MODE_READ))
                        goto err_unlock;


instead of:

Code: Select all

                pcred = __task_cred(p);
                if (cred->euid != pcred->euid &&
                    cred->euid != pcred->uid &&
                    !capable(CAP_SYS_PTRACE))
                        goto err_unlock;


Now, ptrace_may_access(), does check the current process' uid against the target process' euid:

Code: Select all

        tcred = __task_cred(task);
        if ((cred->uid != tcred->euid ||


but not the opposite. This causes this code, run as 'root':

Code: Select all

  seteuid(1);
  get_robust_list(1, &head, &len);


to succeed, while it fails on a non PROC_MEMMAP-enabled kernel.

What is the rationale behind this difference ?

Is there a legitimate application where this actually causes a problem? It's correct that it doesn't match exactly the vanilla permission check, but the vanilla check is broken in serious ways. Regardless, the next patch will only further restrict, instead of replace, any existing check.

Thanks,
-Brad

spender wrote:Is there a legitimate application where this actually causes a problem?

This was caught by running the LTP test suite, specifically the test case that checks the get_robust_list syscall, so that made us question why the euid checks were removed.

So no, no real application that I know of.

Since you're saying that you'll put back the euid checks in future versions, we'll do the same in our current kernel to quiet down LTP.

Thanks,
Ben