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
    
    

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ