From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1423359AbcFGVuT (ORCPT ); Tue, 7 Jun 2016 17:50:19 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:54579 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423344AbcFGVuQ (ORCPT ); Tue, 7 Jun 2016 17:50:16 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Mateusz Guzik Cc: Zhao Lei , linux-kernel@vger.kernel.org, containers@lists.linux-foundation.org, Kamezawa Hiroyuki References: <9d61a9a95ca4c323adc182abf32714b46e963405.1465293010.git.zhaolei@cn.fujitsu.com> <20160607190941.d4hfqehvwxylon4l@mguzik> Date: Tue, 07 Jun 2016 16:38:27 -0500 In-Reply-To: <20160607190941.d4hfqehvwxylon4l@mguzik> (Mateusz Guzik's message of "Tue, 7 Jun 2016 21:09:42 +0200") Message-ID: <878tygfzn0.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX1+ATDGREThw/GOnU/2LUd5078ZxsjajVfs= X-SA-Exim-Connect-IP: 67.3.226.120 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Mateusz Guzik X-Spam-Relay-Country: X-Spam-Timing: total 316 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 3.9 (1.2%), b_tie_ro: 2.8 (0.9%), parse: 1.19 (0.4%), extract_message_metadata: 4.8 (1.5%), get_uri_detail_list: 2.4 (0.8%), tests_pri_-1000: 3.5 (1.1%), tests_pri_-950: 1.19 (0.4%), tests_pri_-900: 0.81 (0.3%), tests_pri_-400: 19 (6.2%), check_bayes: 18 (5.8%), b_tokenize: 4.2 (1.3%), b_tok_get_all: 6 (1.8%), b_comp_prob: 3.0 (1.0%), b_tok_touch_all: 2.9 (0.9%), b_finish: 0.88 (0.3%), tests_pri_0: 266 (84.2%), check_dkim_signature: 0.38 (0.1%), check_dkim_adsp: 2.5 (0.8%), tests_pri_500: 4.1 (1.3%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mateusz Guzik writes: > On Tue, Jun 07, 2016 at 07:29:37PM +0800, Zhao Lei wrote: >> In current system, when we set core_pattern to a pipe, both pipe program >> and program's output are in host's filesystem. >> But when we set core_pattern to a file, the container will write dump >> into container's filesystem. >> >> For example, when we set following core_pattern: >> # echo "|/my_dump_pipe %s %c %p %u %g %t e" >/proc/sys/kernel/core_pattern >> and trigger a segment fault in a container, my_dump_pipe is searched from >> host's filesystem, and it will write coredump into host's filesystem too. >> >> In a privileged container, user can destroy host system by following >> command: >> # # In a container >> # echo "|/bin/dd of=/boot/vmlinuz" >/proc/sys/kernel/core_pattern >> # make_dump >> >> Actually, all operation in a container should not change host's >> environment, the container should use core_pattern as its private setting. >> In detail, in core dump action: >> 1: Search pipe program in container's fs namespace. >> 2: Run pipe program in container's fs namespace to write coredump to it. >> >> This patch fixed above problem by running pipe program with container's >> fs_root. >> > > This does not look sufficient, but I can't easily verify. > > For instance, is the spawned process able to attach itself with ptrace > to processes outside of the original container? Even if not, can it > mount procfs and use /proc/pid/root of processes outside of said > container? > > The spawned process should be subject to all limitations imposed on the > container (which may mean it just must be in the container). Pretty much. The most constructive suggestion I have seen is to have the containers init process logically fork in the kernel and spawn a process that way. Anything that uses call_usermodehelper is trivially not safe because of these concerns. Eric