Re: [PATCH v2 1/2] procfs: make /proc/*/{stack,syscall,personality} 0400

From: Andrew Morton
Date: Fri Mar 28 2014 - 18:32:43 EST


On Sat, 22 Mar 2014 14:37:39 +0100 Djalal Harouni <tixxdz@xxxxxxxxxx> wrote:

> These procfs files contain sensitive information and currently their
> mode is 0444. Change this to 0400, so the VFS will be able to block
> unprivileged processes from getting file descriptors on arbitrary
> privileged /proc/*/{stack,syscall,personality} files.
>
> This reduces the scope of ASLR leaking and bypasses by protecting
> already running processes.

Sigh. Why on earth did we make these 444 in the first place.

There is risk of breakage here. Probably anyone who is using these
files and who observes such breakage is a sophisticated user who
understands the reasons and knows how to make the tools work again.
There's only one way to find out :(

I can't remember why we even added /proc/pid/syscall - the changelog
doesn't give a rationale (this is regrettably common).

Now for a six-year-late code review:

- How the heck can target==current in task_current_syscall()?

- Less talk, more action:

From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Subject: lib/syscall.c: unexport task_current_syscall()

It is only used by procfs and procfs cannot be a module.

Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

lib/syscall.c | 1 -
1 file changed, 1 deletion(-)

diff -puN lib/syscall.c~a lib/syscall.c
--- a/lib/syscall.c~a
+++ a/lib/syscall.c
@@ -72,4 +72,3 @@ int task_current_syscall(struct task_str

return 0;
}
-EXPORT_SYMBOL_GPL(task_current_syscall);
_

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/