Обнаружена очередная local root уязвимость в ядре Linux 3.8

Замапить страницы памяти гостя и мастера в одно место.

ну и как после этого заработает сетевая карта в госте?

з.ы.:

если у проца/матери есть iommu, и в виртуализаторе очередной кусок бажистого кода с неограниченными привилегиями, то вроде как можно выдать гостю настоящую, а не эмулируемую сетевую карту — ты может об этом говорил?

http://scarybeastsecurity.blogspot.it/2009/02/linux-kernel-minor-seccomp.html Пичалька, по твоей логике и seccomp нельзя использовать.

пааааааадумаешь — the bug is not a full break out, just some leakage of filesystem names via stat() or mischief via unrestricted chmod().

неверно — надо лишь оторвать сетевой стек

омг, так ты думаешь этим все проблемы линуха решаться? Что в других подсистемах дырки не находят? Пфф, тоже мне инновации. tcp-стек в юзерспейсе ты хоть сейчас можешь сделать через raw sockets, если хочешь. Выше ссылки кидали.

ну и как после этого заработает сетевая карта в госте?

Используя свои зачатки микроядра ты можешь прокидывать tcp/ip внутрь виртуалок без сетевых интерфейсов. Я это даже где-то видел, но не помню где.

пааааааадумаешь

Речь там больше была об этом: However, I still find this vulnerability interesting. It's a sobering reminder that even a very simple security technology can have surprising bugs.

омг, так ты думаешь этим все проблемы линуха решаться? Что в других подсистемах дырки не находят? Пфф, тоже мне инновации.

не думаю; находят; это во всяком случае лучше, чем сейчас слепил троечник торвальдс

а в других подсистемах ядра вопрос внесения микроядерности улучшения архитектуры посложнее будет, так что я пока про них пока ничего и не говорил

Используя свои зачатки микроядра ты можешь прокидывать tcp/ip внутрь виртуалок без сетевых интерфейсов. Я это даже где-то видел, но не помню где.

как раз интересно такое посмотреть, и главное через что они прокидывают

а еще интересно прокидывать tcp/ip внутрь seccomp — тут тебе самая легковесная (и видимо самая надежная) виртуалка, хотя и на 1 процесс

tcp-стек в юзерспейсе ты хоть сейчас можешь сделать через raw sockets, если хочешь

лучше бы готовый взять

это во всяком случае лучше, чем сейчас слепил троечник торвальдс

Да тут каждый второй на лоре «знает» как лучше, тоже мне удивил :).

тут тебе самая легковесная (и видимо самая надежная) виртуалка

Очень нишевое решение. Самое надёжное и самое ограниченное.

как раз интересно такое посмотреть, и главное через что они прокидывают

по-моему, дрова fiber channel или ещё чего-то для построения кластеров это умели. Я как-то нагугливал. У них ещё remote dma есть.

ядро знает что такое процесс; ядро также знает что такое порт-определенного-протокола, и какие процессы висят на каких портах (в частности, оно может не позволять двоим процессам слушать один порт или позволить это (если надо))

Ты сейчас, что-ли, выкидываешь все протоколы кроме TCP и UDP? Ладно, фиг с ARP. Но как будет работать UDP-мультикаст, которому нужен IGMP? Как будут работать утилиты ping и mtr? Наконец, как твой процесс получит какой-нибудь ICMP connection refused?

хотя *физически* это скорее всего будет таблица скажем 64Кпорта*4байта=256кб на каждый сетевой интерфейс

Во-первых, забываешь про TCP+UDP, и что любое количество процессов могут юзать один порт (форкающийся апач — как пример)... Во-вторых, а маршрутизация тут где будет? Если я посылаю пакет на 192.168.1.5, то как ядро узнает, в какой интерфейс надо выплюнуть этот пакет? А может вообще не в интерфейс, может это мой адрес, и надо передать его другому процессу?

Отдельную головную боль ты заработаешь, когда попытаешься описать обеспечение безопасности в такой системе. А то получится, что у тебя процесс любого юзера, открывший 80й порт, будет получать все http-пакеты и снифать все пароли. И файрвол у тебя не будет ничего блокировать, потому что будет всего лишь одним процессом из многих равноправных.

Нет. Но, насколько я понимаю, даже в этой статье _драйвер_ выжал из карты полную производительность.

Да, без генерации и разбора протокола, просто флудить в сеть заранее подготовленными гигабайтами пакетов. Да и то на нестандартном для миникса формате сообщений, а может и вообще без железа, в смысле, драйвер способен сгенерировать подобный поток, а скормил ли он его в железо или просто дропнул из статьи не ясно.

я совершенно не въехал в этот абзац про файлы

У сетевых сокетов и файлов общий пул дескрипторов, и обрабатываются они теми же функциями (select, read, write, close). Они должны выделяться и обрабатываться в одном месте, иначе кусок кода, выделяющий дескриптор под очередной файл, не будет знать, какие дескрипторы заняты, а какие свободны.

Кроме того процесс может передать свой открытый сокет другому процессу, через fork+exec либо через sendmsg. И ты не сможешь сделать этот сокет «виртуальным», т.е. выделить его внутри своей библиотеки и не показывать ядру. Вот и получается, что сокеты, банальные сокеты, которые выделяются вызовом socket(), должны выделяться в ядре в любом случае. И всякие буферы для этого сокета тоже будут в ядре.

даже в этой статье _драйвер_ выжал из карты полную производительность.

Да, без генерации и разбора протокола, просто флудить в сеть заранее подготовленными гигабайтами пакетов.

Ну да. Понятно, что при разнесении драйвера и стека по разным процессам именно обмен между этими процессами станет узким местом.

Есть несколько демонов, каждый из которых отвечает за свой вид дескрипторов (файлы, сокеты). И есть единое микроядро, выделяющее дескрипторы портов.

Это понятно. Но товарищ же предлагает сделать разбор данных не в отдельном демоне, а в библиотеке, т.е. каждый процесс будет иметь свой разборщик. А тогда микроядро должно будет каким-то чудом определять, кому отдать на разбор очередной пакет.

Но товарищ же предлагает сделать разбор данных не в отдельном демоне, а в библиотеке, т.е. каждый процесс будет иметь свой разборщик.

А я объясняю товарищу, что его идея неработоспособна :) Точнее, пытался объяснить, но забил.

код для разбора пакета в ядре есть [...] однако, этот код stateless и очень туп — на уровне смещений в пакете (или file magic)

Насколько «туп»? VLAN-тегирование может изменить тебе все смещения в пакете, вланы будут разбираться в ядре? Но IP-пакет может быть фрагментирован и в очередном фрагменте может вообще не быть номера порта, IP тоже будет разбираться в ядре? TCP-порт из пакета тоже, очевидно, будет разбираться в ядре. А если пакет придет на закрытый порт, кто будет посылать RST-ответ? Генерация TCP-пакетов тоже будет в ядре? А что ж тогда будет в твоей библиотеке?