Chrome під Docker: CAP_SYS_ADMIN проти привілейованих? [зачинено]


11

У моєму тестовому середовищі я запускаю хромодрук + хром всередині Docker.

До останнього оновлення CoreOS все працювало чудово.

Ось такі версії, які, здається, працюють:

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

І це новіша версія, яка призводить до того, що хром буде збиватися:

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

З огляду на зміни, здається, що докер був оновлений з 1.11.x до 1.12.x, що перервало setns()виклик усередині контейнера. setns()використовується Chrome для створення просторів імен.

Ось приклад виходів:

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

Зсередини один контейнер у цій коробці:

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

Ось як це зламала нова версія:

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)

Що я з’ясував, це те, що якщо я запускаю контейнер з будь-яким --cap-add=SYS_ADMINабо --privileged- Chrome працює так, як очікувалося.

Яка різниця між цими двома перемикачами? Які можливості включені --privileged?

І чи можу я дозволити setns()всередині контейнера без шкоди для безпеки?


Дякую за це Я зробив проблему, використовуючи багато ваших матеріалів: github.com/docker/for-linux/isissue/496 Я думаю, що це слід виправити
— Merc

Я майже на 2 роки занадто пізно, але в квитку вище є набагато краще та безпечніше рішення, якщо ви все ще зацікавлені.
— Merc

Якщо оригінальний плакат не оновлює відповідь (він взагалі не здається активним на SO), дайте мені знати, чи зможете ви прийняти інший. Я витрачав години на це, можу лише уявити, скільки годин ми врятуємо інших людей.
— Merc

Відповіді:


7

AFAICS, документація пропонує надання можливостей, необхідних для контейнера, а не використання --privilegedкомутатора. Запуск у привілейованому режимі, здається, надає контейнеру всі можливості (саме ті, які вказані в першій URL-адресі, за умови оновлення документів).

Коротше кажучи, я б сказав, що --cap-add=SYS_ADMINконтейнер надає менший набір можливостей порівняно з --privilegedкомутатором. Приклади прикладів у документації Докера (перша URL-адреса), здається, вважають за краще просто додати SYS_ADMINабо NET_ADMINможливості, якщо це потрібно.


Спасибі, exec_linux.goдопомогли. Я спробував клонувати докер-репо, щоб проглянути його, але оскільки це зайняло у мене пару годин, я просто забув про це :)
— Яков Сосич

Просто для запуску Chrome, тут є набагато краще рішення: github.com/docker/for-linux/isissue/496#issuecomment-441149510 Я думаю, що було б дуже корисно оновити відповідь, щоб люди робили те, що я пояснюю в той самий коментар. Будь ласка, повідомте мене, якщо ви згодні.
— Merc

1

Одна відмінність полягає в тому, що - привілейовані mounts / dev та / sys як RW, де SYS_ADMIN встановлює їх як RO. Це означає, що привілейований контейнер має повний доступ до пристроїв у системі. SYS_ADMIN цього не дає.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.