From: ebiederm@xmission.com (Eric W. Biederman)
To: Jann Horn <jann@thejh.net>
Cc: Linux Containers <containers@lists.linux-foundation.org>,
linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
Andy Lutomirski <luto@amacapital.net>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [REVIEW][PATCH] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access
Date: Mon, 17 Oct 2016 12:33:33 -0500 [thread overview]
Message-ID: <87wph6op76.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20161017172547.GJ14666@pc.thejh.net> (Jann Horn's message of "Mon, 17 Oct 2016 19:25:47 +0200")
Jann Horn <jann@thejh.net> writes:
> On Mon, Oct 17, 2016 at 11:39:49AM -0500, Eric W. Biederman wrote:
>>
>> 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).
>>
>> This problem is fixed with only necessary userspace breakage by adding
>> a user namespace owner to mm_struct, captured at the time of exec,
>> so it is clear in which user namespace CAP_SYS_PTRACE must be present
>> in to be able to safely give read permission to the executable.
>>
>> The function ptrace_may_access is modified to verify that the ptracer
>> has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns.
>> This ensures that if the task changes it's cred into a subordinate
>> user namespace it does not become ptraceable.
>
> This looks good! Basically applies the same rules that already apply to
> EUID/... changes to namespace changes, and anyone entering a user
> namespace can now safely drop UIDs and GIDs to namespace root.
Yes. It just required the right perspective and it turned out to be
straight forward to solve. Especially since it is buggy today for
unreadable executables.
> This integrates better in the existing security concept than my old
> patch "ptrace: being capable wrt a process requires mapped uids/gids",
> and it has less issues in cases where e.g. the extra privileges of an
> entering process are the filesystem root or so.
>
> FWIW, if you want, you can add "Reviewed-by: Jann Horn
> <jann@thejh.net>".
Will do. Thank you.
Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-10-17 17:33 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-17 16:39 [REVIEW][PATCH] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access Eric W. Biederman
2016-10-17 17:25 ` Jann Horn
2016-10-17 17:33 ` Eric W. Biederman [this message]
2016-10-18 13:50 ` Michal Hocko
2016-10-18 13:57 ` Jann Horn
2016-10-18 14:56 ` Eric W. Biederman
2016-10-18 15:05 ` Jann Horn
2016-10-18 15:35 ` Eric W. Biederman
2016-10-18 19:12 ` Jann Horn
2016-10-18 21:07 ` Eric W. Biederman
2016-10-18 21:15 ` [REVIEW][PATCH] exec: Don't exec files the userns root can not read Eric W. Biederman
2016-10-19 6:13 ` Amir Goldstein
2016-10-19 13:33 ` Eric W. Biederman
2016-10-19 17:04 ` Eric W. Biederman
2016-10-19 15:30 ` Andy Lutomirski
2016-10-19 16:52 ` Eric W. Biederman
2016-10-19 17:29 ` Jann Horn
2016-10-19 17:32 ` Andy Lutomirski
2016-10-19 17:55 ` Eric W. Biederman
2016-10-19 18:38 ` Andy Lutomirski
2016-10-19 21:26 ` Eric W. Biederman
2016-10-19 23:17 ` Andy Lutomirski
2016-11-17 17:02 ` [REVIEW][PATCH 0/3] Fixing ptrace vs exec vs userns interactions Eric W. Biederman
2016-11-17 17:05 ` [REVIEW][PATCH 1/3] ptrace: Capture the ptracer's creds not PT_PTRACE_CAP Eric W. Biederman
2016-11-17 23:14 ` Kees Cook
2016-11-18 18:56 ` Eric W. Biederman
2016-11-17 23:27 ` Andy Lutomirski
2016-11-17 23:44 ` Eric W. Biederman
2016-11-17 17:08 ` [REVIEW][PATCH 2/3] exec: Don't allow ptracing an exec of an unreadable file Eric W. Biederman
2016-11-17 20:47 ` Willy Tarreau
2016-11-17 21:07 ` Kees Cook
2016-11-17 21:32 ` Willy Tarreau
2016-11-17 21:51 ` Eric W. Biederman
2016-11-17 22:50 ` [REVIEW][PATCH 2/3] ptrace: Don't allow accessing an undumpable mm Eric W. Biederman
2016-11-17 23:17 ` Kees Cook
2016-11-17 23:28 ` [REVIEW][PATCH 2/3] exec: Don't allow ptracing an exec of an unreadable file Andy Lutomirski
2016-11-17 23:29 ` Andy Lutomirski
2016-11-17 23:55 ` Eric W. Biederman
2016-11-18 0:10 ` Andy Lutomirski
2016-11-18 0:35 ` Eric W. Biederman
2016-11-17 17:10 ` [REVIEW][PATCH 3/3] exec: Ensure mm->user_ns contains the execed files Eric W. Biederman
2016-11-19 7:17 ` [REVIEW][PATCH 0/3] Fixing ptrace vs exec vs userns interactions Willy Tarreau
2016-11-19 9:28 ` Willy Tarreau
2016-11-19 9:33 ` Willy Tarreau
2016-11-19 18:44 ` Eric W. Biederman
2016-11-19 18:35 ` Eric W. Biederman
2016-11-19 18:37 ` Eric W. Biederman
2016-10-19 18:36 ` [REVIEW][PATCH] exec: Don't exec files the userns root can not read Andy Lutomirski
2016-10-18 18:06 ` [REVIEW][PATCH] mm: Add a user_ns owner to mm_struct and fix ptrace_may_access Michal Hocko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wph6op76.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=containers@lists.linux-foundation.org \
--cc=jann@thejh.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@amacapital.net \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).