> ооо мёёд, просто мёёд, уязвимость в grsecurity! как же так? где ж
> твой друг paxuser, где его главная песнь?Я как-то совсем не уверен что paxuser считает меня своим другом, однако это не мешает мне считать что он довольно грамотен с технологической точки зрения. А вот такого жирного но при этом довольно глупого троллинга от тебя я что-то не ожидал. Мне казалось что если уж хочется потроллить, то можно это и менее топорно сделать :)
> да это наброс, хотя лучше на этом тред и закончить :)
Типа, пукнул и в кусты? Не, так не пойдет :)
> для меня в плане ядра линукса и всех эти "типа" патчей все давно понятно.
Лично мне понятно только то что в мире есть люди, которых безопасность волнует даже сильнее чем разработчиков ядра и они не против затянуть гайки. Я не вижу чего в этом плохого.
> 1) в ядре линя часто находят много дыр
А есть железная уверенность что у остальных качество кода - принципиально лучше, и проблем затрагивающих безопасность - меньше? А на основании чего эта уверенность возникает? Надеюсь на чем-то более серьезном чем на принципах неуловимого Джо?
> 2) исходя из 1 нужно придумать новый grsec, pax, и патчи
Ты так говоришь, как будто баги делают только линуксные програмеры. А остальные наверное супербоги и никогда не ошибаются. Ага. Очень убедительно. А мне почему-то кажется логичным предположить что квалификация програмеров в других проектах не отличается на порядки. А значит количество багов на кило кода - примерно одинаковое, плюс-минус ессно, но даже если их в 2 раза меньше, врядли тебя это сильно утешит если тебе через "в 2 раза более редкий" баг сплойт присвистит, а? :). Это раз. А два состоит в том что я могу тебе гарантировать что в системах с таким объемом кода просто не может не быть багов. Включая баги являющиеся проблемами безопасности. От этого особо никуда не денешься. Разве что заменить програмеров машинами, которые ощибаться не будут. Но машины то тоже делали люди, так что не прокатит это. Единственное что можно - постараться минимизировать количество багов, сделать практически полезную эксплуатацию сложной и минимизировать последствия в случае если плохие парни все-таки прорвутся. Есть какие-то реалистичные идеи лучше? Минимизация кода со своей стороны имеет обратную проблему: система которая ничего не умеет - никому нафиг не нужна. При этом как-то уже и не важно насколько там она будет секурная.
> 3) исходя из 1 и 2 один фиг нужно чуть ли не ежедневно накатывать патчи на ядро
На самом деле это вытекает из
1) Размера кода. Он большой. Это неизбежно. Кому не нравится - запретите выпускать сложное оборудование, а?! Или как ты себе представляешь например простой драйвер для видеокарт со спеками на 1000 страниц, который бы использовал весь функционал, а?КАк ты понимаешь, драйвер реализующий только галимый VGA 640x480х256цветов - нужен сильно меньшему количеству народа чем драйвер с акселерацией 2D, 3D и прочая.
2) Того что люди могут делать ошибки.
3) Из 1) и 2) следует что чем больше код, тем больше багов. Равно как и патовая ситуация состоящая в том что те кто хочет поддерживать все современное оборудование и его фичи, более-менее все протоколы, етц - не могут сделать код совсем без багов. Потому что времена ключа Морзе в котором негде возникнуть багам и одного тривиального протокола, который сложно реализовать неправильно - прошли. И не хотят вот теперь двуногие настукивать линейный код в линию самолично. Совсем обленились, сцуки - все на процессоры сбагрили! :).
> 4) исходя из 1,2,3 нужно придумать как меньше тратить времени на перезагрузки
> (ау ksplice, upstart, etc)
А? Чо? Батхерт по поводу отсутствия функционала при ядре сравнимого размера и сложности а потому - наврядли меньшим числом багов там? Хаха, отжиг :). Еще можно упомянуть виртуализаторы и перемещение контейнеров/виртуалок между машинами. Кто там из теоретиков хотел процессы-странники? История прикололась и странниками становятся целые операционки :)
> 5) ждем новой дыры, и гото 1.
Кэп, скажи, а в твоей любимой системе этот алгоритм чем-о отличается? :)
> Скоро линь будет грузиццо за 0,5 секунды,
Если сильно захотеть - можно в космос полететь. Пруфлинк: нечто типа google://linux boot in second :)
> а патчи на ядро применяться прозрачно, вот он профит! :))
А что, красивая технология, созданная для жизни. Для людей. Идеальная система тратит минимум времени и ресурсов на служебные внутренние операции, мля. Загрузка системы - служебная операция по определению. Она не нужна пользователю, пользователю нужна система, программы в ней и то что они делают. И я затрудняюсь сказать что скажем рестарт допустим IP камеры видеоналюдения после заливки новой фирмвари за пару секунд вместо пары минут - это плохо.Не, нифига, это - хорошо, правильно и так как и должно быть с самого начала :)
Hint: мой первый компьютер загружался на горячую из рамдиска в допиленный местными аборигенами вариант CP/M за ~пару секунд. И это при хилом 8080 проце на 3МГц, тормозной в хлам оперативке и прочая. Мне не понятно почему это стоит считать роскошью при том что мощности процессоров, даже маленьких и экономных выросли в тысячи раз, равно как и скорости оперативки и всех интерфейсов. Это не роскошь, это - нормально. Это так как должно быть, если систему делать не жопой к юзеру а лицом. Ы?
Вариант для распечатки
