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

Заимели две частично несовместимые версии 12.04 убунты.

На старую версию - да и хрен с ней. Все ставят обновления и ставят обновлённую версию.

То, что они «ниасилят» и через полгода-год у нас опять будет «счастье».

Ты - пользователь убунты? :) По-моему, нет.

На старую версию - да и хрен с ней.

А как же LTS? Или тоже хрен бы с ней?

Все ставят обновления и

Все как сидели на 3.2 так и будут сидеть, 3.5 само не накатится, а если вдруг накатится, то сразу всё поломает.

ставят обновлённую версию.

Ага и прилетит 3.5

Ты - пользователь убунты? :) По-моему, нет.

Да, но не на десктопе.

Верно. И это не зависит от микроядерности. В монолитном ядре все точно так же.

В монолитном можно залезть из битого драйвера вебки в драйвер ФС, или нечаянно (баг -> повреждение данных), или чаянно (эксплоит). Обрезать оба пункта конечно интересно.

Все равно его можно передать вместе с сообщением

Далеко не всегда там есть место для этого. Или место может быть, но write-only для ядра (положить ответ для ioctl, например). А если бы оно еще всегда в non-executable было... <мечтает>

или оставить где-то в shared memory.

Если правильно понял, то об этом уже пытался сказать, есть вроде фича типа NX на всю память юзерспейса.

mmap_min_addr в линуксах тоже осложняет размещение payload-а, но не защищает от всех эксплоитов.

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

Эта сложность в написании эксплоита дается ценой более сложного и медленного кода драйверов. Стоит ли оно того?

Самим драйверам должно быть даже проще, например сразу с preemption. А что медленнее, то тут не спец, но наверное железная архитектура должна способствовать (быстрое переключение контекста), тут да.

Используется она очень редко и осторожно. Но там, где используется, она таки компрометирует и стабильность и безопасность. Пример — гуглохром, в котором память расшарена между множеством его процессов. Казалось бы, если один процесс упадет, то остальные должны работать, а на практике хром очень часто падал целиком из-за этой самой шареной памяти.

Интересное использование, сначала поделить всё для безопасности, а потом сливать назад. К «редко»:

# ipcs -m | wc -l
94

PS: Мы тут разошлись по теме shared memory, а ведь она в minix-е появилась совсем недавно, где-то в середние 3й версии, и ее пока что почти никто не использует, вероятно, потому что это слишком усложняет и без того непростое взаимодействие между системными процессами.

Или потому что уже привыкли делать IPC через что-то другое :) Или просто не горит. С сабжем не знаком, к сожалению.

Работать будет, если будет, только на 64-битной системе

На 3.7.9-205.fc18.x86_64 не работает

А как же LTS? Или тоже хрен бы с ней?

А чем аббревиатура LTS противоречит обновлениям?

Все как сидели на 3.2 так и будут сидеть, 3.5 само не накатится, а если вдруг накатится, то сразу всё поломает.

Что оно поломает, можно развернуть?

Да, но не на десктопе.

Заметно, что мало где. Ты бы эта... Троллить толсто бы перестал, а то превращается во второго Irsi на свой лад (только хуже). А такие как Irsi рано или поздно помещаются в бан.

Просто их туда меееедленно впиливают :)

Хи-хи. Зато туда и баги мееееедленно впиливают :)... а обычно вообще не впиливают. Мало даже уязвимостей, так ведь и банальный hibernate лично у меня на ноуте на 3.7 отвалился во всех вариантах ядер - debian experimental, aptosid, liquorix, ubuntu. А раз такое распространение, я тихо подозреваю что это баг апстрима, хотя конечно не проверял ещё.

Ну и киллерфич чо-то я не видел в 3.7-3.8 по сравнению с 3.2. Вроде-бы в радеон драйвере улучшения какие-то, но что-то я сомневаюсь, что такие уж колоссальные.

Кстати никто не знает, как это дебажить, когда при гибернации оно говорит Snapshotting system, потом делает чёрный экран и мигает капсом? Нумлока и скролллока на клавиатуре ноута нет, так что мигают ли они, доложить не могу.

А чем аббревиатура LTS противоречит обновлениям?

Обновления не должны ломать совместимость.

Что оно поломает, можно развернуть?

Если у тебя специфическое железо, привязанное блобами к 3.2, то что делать будешь?

Когда у тебя сервер собран из старенького desktop'ного компа сына, то проще. А если это серверная мать с отдельной платой рэйд-контроллера, то только на всякие самопроверки ещё до старта загрузчика ОС уходит порядка 2-х минут.

ты про понятие «профилактика» когда-нибудь слышал? У тебя боевой сервер? Который работает 24/7/365? ОДИН??? Ты либо админ локалхоста, либо идиот.

Если у тебя специфическое железо, привязанное блобами к 3.2, то что делать будешь?

менять железо. Очевидно же!

А если поменять не на что?

А если поменять не на что?

ИМХО эта проблема никак к версии ядра не относится. Не уподобляйся вендотроллям, которые юзают свою WinXP из-за того, что у них нет денег на новый принтер.

если вдруг накатится, то сразу всё поломает

> Что оно поломает, можно развернуть?

Если у тебя специфическое железо, привязанное блобами к 3.2, то что делать будешь?

Reset™

// мимо проходил

суровые слакоадмины видимо привыкли менять пачку серверов по приказу патрика

Если у тебя специфическое железо, привязанное блобами к 3.2, то что делать будешь?

Это какое такое железо?

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

Ну так а в чём же дело? Зачем на железо, спроектированное с поддержкой RHEL, вкрячивать Ubuntu?

Debian sid, и мы не без пряников отработал эксплоит.

Ты похоже совсем не понимаешь о чем я говорю. Проблема в том, что железо «спроектированное с поддержкой» Ubuntu LTS вдруг может перестать на ней работать.

Я прекрасно понимаю. Но хотелось бы примеров явных, а не гипотетических.

ты про понятие «профилактика» когда-нибудь слышал? У тебя боевой сервер? Который работает 24/7/365? ОДИН??? Ты либо админ локалхоста, либо идиот.

Похоже, идиот здесь ты как раз. Ты про нештатные ситуации что-нибудь слышал?

Расскажи мне как _ты_ полностью резервируешь ядро сети.

Повторю специально для тебя - я не видел ни одной сети, где было бы полное резервирование, хотя бы, ядра. Люди из разряда конченных фэнов сиськи покупают девайсы за тонны килобаксов в ядро и как-то не парятся полным резервированием, ибо это стоит огромных денег и является _непозволительной_ роскошью в условиях текущего экономического строя мира. И если у больших контор нет таких денег, откуда они возьмутся у контор за пределами дефолт сити?

Резервирование делается по-другому. В виде оборудования, которое обладает необходимыми параметрами для того, что бы заменить любой узел сети, будучи в случае необходимости прошито/настроено верным образом. Но при _нештатных_ ситуациях проще сделать быстрый ребут, при необходимости, чем мутить резерв - уйдёт больше времени.

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

Похоже, идиот здесь ты как раз. Ты про нештатные ситуации что-нибудь слышал?

я - да. Ты хочешь сказать, что в момент внештатной ситуации тебе надо только просто взять, и перезагрузить? И тут главное, 2 или 10 минут будет перезагрузка идти? А так всё само подымется? Ну у меня какие-то другие нештатные ситуации, там перезагрузка не поможет.

Но при _нештатных_ ситуациях проще сделать быстрый ребут

ну и чем оно тебе поможет?

Расскажи мне как _ты_ полностью резервируешь ядро сети.

ставятся два сервера, и нагрузка делится между ними. Получается быстро и просто. Один сервер может рухнуть, второй будет работать за двоих. Очевидно, юзер заметит, что ресурс стал тупить вдвое больше. Ну и что?

Есть ещё и облака - там скажем 10 серверов, а не один. В любой момент можно один из них остановить и ребутить хоть весь день. Клиент всё равно ничего не заметит.

Резервирование делается по-другому. В виде оборудования, которое обладает необходимыми параметрами для того, что бы заменить любой узел сети,

это какое-то другое резервирование.

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

даже в ущерб штатной работоспособности?

...
Ну у меня какие-то другие нештатные ситуации, там перезагрузка не поможет.

Я всё больше думаю, что у тебя их, вообще, нет.

Но при _нештатных_ ситуациях проще сделать быстрый ребут

ну и чем оно тебе поможет?

Ты на факультете журналистики учишься что ли? Максимально отрезать цитату можно было так:

«Но при _нештатных_ ситуациях проще сделать быстрый ребут, при необходимости»

Не умеешь цитировать - не берись. Объяснять какая необходимость может быть не буду. Появится опыт администрирования сколько-нибудь большой сети - сам узнаешь.

Расскажи мне как _ты_ полностью резервируешь ядро сети.

ставятся два сервера, и нагрузка делится между ними. Получается быстро и просто. Один сервер может рухнуть, второй будет работать за двоих. Очевидно, юзер заметит, что ресурс стал тупить вдвое больше. Ну и что?

:-D Ты насмешил меня до слёз. Я просил тебя рассказать про твоё ядро сети, но очевидно у тебя его нет ни под рукой, ни где-то рядом :-), поэтому ты мне тут рассказываешь детские сказочки про два сервера :-D.

Так вот, специально для тебя. Во-первых, ты знаешь сколько может стоить труЪ сервер с сертификатами мин.связи? Такая машина легко взлетит до 200000-250000руб. Это стоечный корпус с _одной_ матерью внутри на два проца всего-то. И ты серьёзно предполагаешь, что, когда ты подойдёшь к начальству с требованием купить ещё такой же, тебя не пошлют на@#й? Во-вторых, в сколько-нибудь большой сети стоит не один сервер, а много, и это не считая другого активного оборудования (коммутаторы, маршрутизаторы, wdm и т.п.). В сумме всё это потянет на поллимона-лимон. Как ты это будешь полностью резервировать?

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

Есть ещё и облака - там скажем 10 серверов, а не один. В любой момент можно один из них остановить и ребутить хоть весь день. Клиент всё равно ничего не заметит.

Какие нахер облака? Вот, наебнётся маршрутизатор/шейпер, через который все твои 10 серверов подключены к внешней сети и привет. Никто не делает облака из dlink/cisco/juniper.

Резервирование делается по-другому. В виде оборудования, которое обладает необходимыми параметрами для того, что бы заменить любой узел сети,

это какое-то другое резервирование.

Это real-life резервирование. Добро пожаловать в реальный мир. Ты можешь купить доп.модули sfp, резервный блок питания, но просто зарезервировать целиком железку за поллимона не получится.

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

даже в ущерб штатной работоспособности?

Что это значит? Если надо ребутнуть железку, то быстрый ребут лучше медленного. При чём тут «штатная работоспособность»? Что это, вообще, за термин?

Попробуй на нормальном линаксе, на арче, например....

Linux porese 3.7.9-2-ARCH #1 SMP PREEMPT Mon Feb 25 12:29:24 CET 2013 i686 GNU/Linux

эксплойт не работает, пеши новый!

Кстати, кто-нибудь с grsec проверял эксплоит?

Ты на факультете журналистики учишься что ли?

не. Я потомственный демагог.

Я всё больше думаю, что у тебя их, вообще, нет.

впрочем, ты не лучше: и на личности перешёл, и авторитетом надавил, и стрелки перевёл, но на вопрос - так и не ответил.

Но при _нештатных_ ситуациях проще сделать быстрый ребут, при необходимости

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

Ты расскажи мне, глупому одмину локалхоста, а то мне непонятно.

Так вот, специально для тебя. Во-первых, ты знаешь сколько может стоить труЪ сервер с сертификатами мин.связи?

нет. Я не занимаюсь покупкой серверов, не стою в очереди за сертификацией в минсвязи, да и вообще-то я 3.5 раза в серверной был. Что мне там делать-то?

И вот именно потому, я не понимаю, какая связь между «резервированием» и «стоимостью сертификации». Наверное есть связь, но она от меня ускользает.

И ты серьёзно предполагаешь, что, когда ты подойдёшь к начальству с требованием купить ещё такой же, тебя не пошлют на@#й?

нет. Пошлют тебя. Потому-что ты тут рассуждаешь о минутах, и даже не догадываешься, сколько эти минуты простоя стоят. А стоят они ДОРОГО. И между прочим, в ТЗ чётко расписано, сколько минут в году твой сервер будет «перезагружаться». Ну и ещё не забудь о том, что два сервера, в два раза слабее, стоят ненамного дороже, чем один мощный. Дороже, но не намного. Причём работать они будут почти всегда ВМЕСТЕ, а вот fuckup наступит, когда они упадут СРАЗУ. Что очень мало вероятно, при должном обслуживании и профилактике.

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

откуда я-то знаю? повторяю: железками типа твоих коммутаторов я не занимаюсь. Народ говорил чё-то про резервные каналы, по котором траф идёт в случае сбоя какого-то коммутатора, и у народа такие каналы есть. Это для них - естественно, и их ещё никто никуда не послал. Если тебе это интересно - пообщайся, тебе расскажут.

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

пионер-нет проблемы? Все ваши 3К юзеров плачут? Мне их жаль. Нормального ISP нет что-ли?

Какие нахер облака? Вот, натся маршрутизатор/шейпер, через который все твои 10 серверов подключены к внешней сети и привет.

мои территориально разбросаны, и подключены к разным магистралям. Остынь. Облако != стойке с 10ю железками.

Никто не делает облака из dlink/cisco/juniper.

с этим я и не спорил. Да и не предлагал. Не путаешь ни с кем меня?

Добро пожаловать в реальный мир. Ты можешь купить доп.модули sfp, резервный блок питания, но просто зарезервировать целиком железку за поллимона не получится.

пионернетпроблемы.

Что это значит? Если надо ребутнуть железку, то быстрый ребут лучше медленного. При чём тут «штатная работоспособность»? Что это, вообще, за термин?

а ты вообще понимаешь, ЧТО происходит во время этого «ребута», и ЧЕГО ты так со своими плачущими юзерами ждёшь? Задумайся.

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

Я всё больше думаю, что у тебя их, вообще, нет.

впрочем, ты не лучше: и на личности перешёл, и авторитетом надавил, и стрелки перевёл, но на вопрос - так и не ответил.

Где это я на личности перешёл? Я тут не на пресс-конференции, что б на вопросы отвечать. Я могу поделиться своим опытом, ты своим. Каждый узнает что-то новое и интересное. Но у тебя такого опыта нет. Так, нафига мне распинаться? Я не понимаю хрен ли рассуждать о чём-то относительно какой-то области применения, если никакого отношения к этой области применения ты не имеешь?

Но при _нештатных_ ситуациях проще сделать быстрый ребут, при необходимости

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

А где я сказал, что больше ничего не надо?

нет. Пошлют тебя. Потому-что ты тут рассуждаешь о минутах, и даже не догадываешься, сколько эти минуты простоя стоят. А стоят они ДОРОГО.

OMG... Да, тебе-то откуда знать сколько они стоят?..

И между прочим, в ТЗ чётко расписано, сколько минут в году твой сервер будет «перезагружаться».

Какое ещё ТЗ? Кто его составил на мой сервер? И зачем?

Ну и ещё не забудь о том, что два сервера, в два раза слабее, стоят ненамного дороже, чем один мощный. Дороже, но не намного. Причём работать они будут почти всегда ВМЕСТЕ, а вот fuckup наступит, когда они упадут СРАЗУ. Что очень мало вероятно, при должном обслуживании и профилактике.

Ещё, не забудь о том, что сеть не состоит из двух серверов. Вот тебе картина:

клиент --> dlink/cisco/juniper ---> vpn ---> shaper ---> bgp

Пусть vpn-серверов 10. Расскажи, как ты сделаешь горячее резервирование dlink/cisco/juniper? Только по-проще. Извращённые схемы я сам могу придумать.

откуда я-то знаю? повторяю: железками типа твоих коммутаторов я не занимаюсь.

Понятно.

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

Ты, вообще, разницу между резервированием канала и резервированием железа понимаешь? Если тебе не сложно, то, пожалуйста, спроси у «народа», а есть у них, хотя бы, холодный полный резерв оборудования на обоих концах всех каналов. Пожалуйста.

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

Начинаешь понимать.

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

Начинаешь понимать.

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

Но вообще-то, это азы. Нагрузка всегда неравномерная, потому скажем ночью часть серверов можно отключить, и сделать профилактику. В т.ч. и ребут. В этом случае аварий можно почти полностью избежать, а если уж случится что, то ребут всё равно не поможет (потому как ошибки и проблемы уже исправленны во время полной профилактики. И случилось СТРАШНОЕ. Против НЁХ ребут бессилен). Ну а раз всё равно не поможет, то какая разница, насколько он быстр?

Уф... Утомил ты меня.

Скажи, ты у «народа» спросишь или нет?

увижу - спрошу. Создай здесь тему, тебе расскажут.

:-D