>Чисто для справки - в тот единственный сплойт, который обезвреживал LSM (через
>дыру в коде tun-драйвера), добавить возможность выхода за пределы контейнера -
>совсем не проблема.

Да, если дело дошло до хоста и его ядра. А удастся ли спровоцировать проблему из контейнера? Судя по всему - удается это далеко не всегда. Насчет скрипткиддисов - нет, я просто давно ничего не ломаю и в данный момент - запускаю эксплойты сугубо на своих системах с целью проверки их дырявости и изучения возможностей их поимения другими.

Кстати контейнеры бывают разные. Если взять полновесный виртуализатор типа Xen-а (хоть и заплатив за это тормозами и потреблением памяти) - для поимения хоста или соседних песочниц ломать надо мелкий гипервизор. Вон у рутковской параноидальная система есть, например. Специально на такие случаи как раз.

>Более того, тот код уже сам по себе был смертельно опасен для всей системы,
>и вместо получения рута туда можно было засунуть и запись в блочные устройства.

Ну да, я понимаю что если ядро хоста раздолбили - можно сделать что угодно. Тем не менее, на практике - из опенвзового контейнера почему-то долбаться вообще не захотело. Насколько я понял - сплойт вообще ниасилил сделать какую-то нужную операцию из контейнера. Кстати не уверен что это было TUN а не сплойт, который махинации с виртуальной памятью юзал (mmap-эксплойт, вроде).

>Повторяю еще раз - практически всем дырам в ядре глубоко наплевать на
>контейнеры. Ядро одно на всех.

Дельно говорите, НО контейнеры изменяют некоторые аспекты работы ядра. Есть подозрение что некоторые из этих изменений могут мешать работе сплойтов. Как минимум могу припомнить что махинации с виртуальной памятью из контейнера не срабатывали совсем, хотя ядро было уязвимое. А на "железке" - работало на ура.