linux-kernel - RE: [PATCH] Fix /proc/[pid]/ns permissions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 9 Apr 2018 22:33:37 +0000
From:   "Banerjee, Debabrata" <dbanerje@...mai.com>
To:     "'Eric W. Biederman'" <ebiederm@...ssion.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        Daniel Lezcano <daniel.lezcano@...e.fr>,
        Linux Containers <containers@...ts.linux-foundation.org>
Subject: RE: [PATCH] Fix /proc/[pid]/ns permissions

> From: Eric W. Biederman [mailto:ebiederm@...ssion.com]
>
> I agree there is an inconsistency on the directory permissions for the ns
> directory that could reasonably be fixed.

So you'd recommend taking this patch as-is?

> prctl(PR_SET_DUMPABLE, 0) is an interesting.  Fundamentally it is about not
> letting unprivileged tasks poke about with the process, and it is the
> mechanism used by setuid/setgid exec.   If you are root in the user
> namespace of the task or your uid created the user namespace or an
> ancestor user namespace you should be able to inspect the process.
> 
> What happens with dumpable is also going to vary a little bit depending on
> how recent your kernel is.  The dumpable status was not really namespaced
> until recently.
> 
> There might also be some issues from yama or other lsms that love to limit
> ptrace.  Though it sounds like your issue is the dumpability.
> 
> The check "ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS)" is the
> standard check for accessing anything even a little bit sensitive of a process,
> and that seems appropriate here.

Why is the namespace inode # secret? If it is because it's an inode, perhaps there is a better way to represent the namespace that is not secret? What we are trying to do is check if link points to the same place as our namespace, the contents don't matter. On the other hand it would be very convenient if pid's not in your namespace, even from a parent namespace, did not appear. That would make user tools work properly without workarounds, i.e. killall, pgrep, ps, top.