| 1.1, hoopoe (ok), 11:34, 13/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 не очень понятно: user space библиотека управляет доступом из контейнера? а что помешает выполнить аналогичный код в другой библиотеке? или она работает вне контейнера?
| | |
| |
| 2.15, sage (??), 11:44, 15/01/2017 [^] [^^] [^^^] [ответить]
| +/– |
Она работает вне контейнера, но дает возможность приложениям, выполняемым в контейнере, которые были запущены через эту утилиту, выполнить ptrace на эту утилиту.
В общем, уязвимость опасна только в том случае, если кто-то сперва модифицировал контейнер, добавив в него вредоносный код в программы, которые вы запускаете через exec, а потом дождался, когда вы выполните exec.
| | |
|
| 1.5, Ванга (?), 14:25, 13/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Только новая архитектура позволит преодолеть слабую изоляцию приложений.
| | |
| 1.7, Celcion (ok), 16:06, 13/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 "Выбраться из контейнера" - это зачет. Как представлю себе "уязвимость, выбирающуюся из контейнера" - так портится сон и аппетит.
| | |
| 1.8, Аноним (-), 16:06, 13/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Кто-то действительно использует Docker для изоляции потенциально опасных приложений? Он же не для того нужен. Повышение безопасности - побочный эффект и я бы не стал на него всерьёз рассчитывать в отношении зловредов. От запуска rm -rf / защитит и ладно...
| | |
| 1.14, Аноним (-), 18:50, 14/01/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Правда данная уязвимость не эксплуатируется на системах с настроенным selinux.
| | |
|
