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?

permissions docker chrome namespaces 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

Jawaban:

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