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-next>] [day] [month] [year] [list]
Date:   Mon, 24 Oct 2016 13:59:59 +0300
From:   Cyrill Gorcunov <gorcunov@...il.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Andrey Vagin <avagin@...tuozzo.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Pavel Emelyanov <xemul@...tuozzo.com>
Subject: [ISSUE] mm: Add a user_ns owner to mm_struct and fix
 ptrace_may_access

Hi Eric! A few days ago we've noticed that our zombie00 test case started
failing: https://ci.openvz.org/job/CRIU/view/All/job/CRIU-linux-next/406/console
---
======================== Run zdtm/static/zombie00 in h =========================
Start test
./zombie00 --pidfile=zombie00.pid --outfile=zombie00.out
Run criu dump
Run criu restore
Send the 15 signal to  30
Wait for zdtm/static/zombie00(30) to die for 0.100000
################ Test zdtm/static/zombie00 FAIL at result check ################

I've narrowed problem down to commit

 | From ce99dd5fd5f600f9f4f0d37bb8847c1cb7c6e4fc Mon Sep 17 00:00:00 2001
 | From: "Eric W. Biederman" <ebiederm@...ssion.com>
 | Date: Thu, 13 Oct 2016 21:23:16 -0500
 | Subject: [PATCH] mm: Add a user_ns owner to mm_struct and fix
 |  ptrace_may_access
 |
 | During exec dumpable is cleared if the file that is being executed is
 | not readable by the user executing the file.  A bug in
 | ptrace_may_access allows reading the file if the executable happens to
 | enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
 | unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).

and the reason is that the zombie tasks do not have task::mm and in resut
we're obtaining -EPERM when trying to read task->exit_code from /proc/pid/stat.

Looking into commit I suspect when mm = NULL we've to move back the test
ptrace_has_cap(__task_cred(task)->user_ns, mode)?

Powered by blists - more mailing lists