Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1416666
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern |
| Date | 2016-06-08 00:00 +0200 |
| Message-ID | <rHxcu-85W-25@gated-at.bofh.it> (permalink) |
| References | <rHlXH-13D-1@gated-at.bofh.it> <rHnwu-25S-17@gated-at.bofh.it> <rHuHE-6FD-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Mateusz Guzik <mguzik@redhat.com> 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
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH v2 0/3] Write dump into container's filesystem for pipe_type core_pattern Zhao Lei <zhaolei@cn.fujitsu.com> - 2016-06-07 12:00 +0200
[PATCH v2 1/3] Save dump_root into pid_namespace Zhao Lei <zhaolei@cn.fujitsu.com> - 2016-06-07 13:40 +0200
[PATCH v2 2/3] Make dump_pipe thread possilbe to select the rootfs Zhao Lei <zhaolei@cn.fujitsu.com> - 2016-06-07 13:40 +0200
[PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern Zhao Lei <zhaolei@cn.fujitsu.com> - 2016-06-07 13:40 +0200
Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern Mateusz Guzik <mguzik@redhat.com> - 2016-06-07 21:20 +0200
Re: [PATCH v2 3/3] Write dump into container's filesystem for pipe_type core_pattern ebiederm@xmission.com (Eric W. Biederman) - 2016-06-08 00:00 +0200
csiph-web