Chrome di bawah Docker: CAP_SYS_ADMIN vs istimewa? [Tutup]

11

Saya menjalankan chromedriver + chrome di dalam Docker di lingkungan pengujian saya.

Semuanya bekerja dengan baik sampai upgrade CoreOS terbaru.

Ini adalah versi yang sepertinya berfungsi:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

Dan ini versi yang lebih baru yang menyebabkan chrome untuk coredump:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

Melihat perubahan, tampaknya buruh pelabuhan ditingkatkan dari 1,11.x ke 1,12.x, yang memutuskan setns()panggilan di dalam wadah. setns()digunakan oleh Chrome untuk membuat ruang nama.

Ini adalah contoh output:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

Dari dalam satu wadah di kotak ini:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

Ini adalah bagaimana versi baru memecahkannya:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

Apa yang saya temukan adalah bahwa jika saya memulai wadah dengan salah satu --cap-add=SYS_ADMINatau --privileged- Chrome berfungsi seperti yang diharapkan.

Apa perbedaan antara kedua sakelar itu? Kemampuan apa yang diaktifkan oleh --privileged?

Dan, bisakah saya mengizinkan setns()di dalam wadah tanpa mengorbankan keamanan?

— Jakov Sosic
sumber

Terima kasih untuk ini. Saya membuat masalah, menggunakan banyak barang Anda: github.com/docker/for-linux/issues/496 Saya pikir itu harus diperbaiki

— Merc

Saya hampir 2 tahun terlambat, tetapi ada solusi yang jauh lebih baik dan lebih aman dalam tiket di atas jika Anda masih tertarik.

— Merc

Jika poster asli tidak memperbarui jawabannya (sepertinya dia sama sekali tidak aktif di SO), beri tahu saya jika Anda bersedia menerima yang lain. Saya menghabiskan waktu berjam-jam untuk hal ini, saya hanya bisa membayangkan berapa jam kita akan menyelamatkan orang lain.

— Merc

7

AFAICS, dokumentasi menyarankan pemberian kemampuan yang dibutuhkan untuk wadah, daripada menggunakan --privilegedsakelar. Menjalankan dalam mode istimewa tampaknya memberikan semua kemampuan pada wadah (persis seperti yang tercantum dalam URL pertama, asalkan dokumen terbaru).

Singkatnya, saya akan mengatakan bahwa --cap-add=SYS_ADMINmemberikan subset yang lebih kecil dari kemampuan untuk wadah, dibandingkan dengan --privilegedsakelar. Acara contoh dalam dokumentasi Docker (URL pertama) tampaknya lebih suka hanya menambahkan SYS_ADMINatau NET_ADMINkemampuan di mana diperlukan.

— ivuk
sumber

Terima kasih sudah exec_linux.gomembantu. Saya mencoba mengkloning repo buruh pelabuhan untuk menerobosnya, tetapi karena butuh beberapa jam, saya lupa saja :)

— Jakov Sosic

Hanya untuk menjalankan Chrome, ada solusi yang jauh lebih baik yang tercantum di sini: github.com/docker/for-linux/issues/496#issuecomment-441149510 Saya pikir akan sangat bermanfaat untuk memperbarui jawaban sehingga orang melakukan apa yang saya jelaskan dalam itu komentar yang sangat. Tolong beri tahu saya jika Anda setuju.

— Merc

1

Satu perbedaan adalah bahwa - mount pribadi / dev dan / sys sebagai RW, sedangkan SYS_ADMIN me-mount mereka sebagai RO. Ini berarti bahwa kontainer istimewa memiliki akses penuh ke perangkat pada sistem. SYS_ADMIN tidak memberi Anda itu.

— mel1990
sumber