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] [thread-next>] [day] [month] [year] [list]

Message-ID: <31CF3F25-8A82-426B-BFA0-6225C39334F5@akamai.com>
Date:   Thu, 5 Apr 2018 18:23:16 +0000
From:   "Banerjee, Debabrata" <dbanerje@...mai.com>
To:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>
CC:     Daniel Lezcano <daniel.lezcano@...e.fr>
Subject: Re: [PATCH] Fix /proc/[pid]/ns permissions

Actually, this patch is incomplete. proc_ns_get_link() and proc_ns_readlink() gate on ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS). I'm not sure why this is here either. It seems problematic that after a user creates a pid namespace, that a user cannot tell anymore which namespace new pids belongs to, including the parent namespace after prctl(). Some mechanism is required here. If ns->inum from ns_get_name() is secret, then at least a flag if it is in your namespace.

-Deb

On 4/5/18, 1:15 PM, "Debabrata Banerjee" <dbanerje@...mai.com> wrote:

    This seems like a bug since the original commit 6b4e306aa3dc. Having ns
    directory be executable but not readable does not make sense. Further,
    it breaks userspace when it needs to know which namespace it belongs
    to. For example, setting a process to prctl(PR_SET_DUMPABLE, 0)
    immediately hides the namespace from that user, breaking the latest
    pgrep with namespace support.
    
    The main problem here is that unlike other namespaces, pid namespaces
    appear flat as you follow the parents upwards in the heirarchy. It is
    important to be able to tell that a process is in your namespace, a
    child namespace, or an entirely different namespace. In the latter
    case, the pid is already hidden from you, thus these permission don't
    matter.
    
    CC: Eric W. Biederman <ebiederm@...ssion.com>
    CC: Daniel Lezcano <daniel.lezcano@...e.fr>
    
    Signed-off-by: Debabrata Banerjee <dbanerje@...mai.com>
    ---
     fs/proc/base.c | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
    
    diff --git a/fs/proc/base.c b/fs/proc/base.c
    index d53246863cfb..2295ac0d8e1c 100644
    --- a/fs/proc/base.c
    +++ b/fs/proc/base.c
    @@ -2922,7 +2922,7 @@ static const struct pid_entry tgid_base_stuff[] = {
     	DIR("fd",         S_IRUSR|S_IXUSR, proc_fd_inode_operations, proc_fd_operations),
     	DIR("map_files",  S_IRUSR|S_IXUSR, proc_map_files_inode_operations, proc_map_files_operations),
     	DIR("fdinfo",     S_IRUSR|S_IXUSR, proc_fdinfo_inode_operations, proc_fdinfo_operations),
    -	DIR("ns",	  S_IRUSR|S_IXUGO, proc_ns_dir_inode_operations, proc_ns_dir_operations),
    +	DIR("ns",	  S_IRUGO|S_IXUGO, proc_ns_dir_inode_operations, proc_ns_dir_operations),
     #ifdef CONFIG_NET
     	DIR("net",        S_IRUGO|S_IXUGO, proc_net_inode_operations, proc_net_operations),
     #endif
    -- 
    2.16.2