|
|
|
4.66, Аноним (-), 17:34, 02/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Увы, иранцам это не помогло, так что отсутствие компьютеров таки безопаснее.
| |
|
3.60, 123 (??), 18:27, 31/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
RMS одобряет. Он таким образом решил для себя проблему с телефонами.
| |
|
4.71, DmA (??), 15:15, 31/08/2018 [^] [^^] [^^^] [ответить]
| +/– |
RMS телефоном пользуется, но только не сотовым, а если приходится пользоваться сотовым, то он его включает когда очень нужно.
| |
|
|
|
1.6, Аноним (-), 11:32, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +5 +/– |
> На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG
Ошибки не исключены на любой стадии.
| |
|
2.17, Andrey Mitrofanov (?), 13:33, 30/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> На текущей стадии разработки авторы не исключают наличия ошибок в коде LKRG
> Ошибки не исключены на любой стадии.
На другой стадии они из будут исключать -- и ошибаться в этом.
| |
|
3.27, solardiz (ok), 15:49, 30/01/2018 [^] [^^] [^^^] [ответить]
| +9 +/– |
Не будем исключать. Это ошибка при составлении новости на OpenNet (но всё равно большое спасибо модераторам что вникли в суть проекта и опубликовали здесь новость). В исходном английском тексте это два разных абзаца - один о том что ошибки и в том числе уязвимости в самом LKRG возможны (и это надо учитывать при принятии решения о его (не-)использовании в конкретном случае) и другой о том что проект на ранней стадии и мы ожидаем ложные срабатывания (из-за чего LKRG пока не принимает жестких мер при обнаружении нарушений).
| |
|
|
1.7, Аноним (-), 11:51, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
| |
|
|
3.9, Аноним (-), 12:21, 30/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> Можно уменьшить потерю производительности ценой небольшого повышения потребления памяти, создав полную копию статичных частей ядра, которые будут расшарены, и отлавливая изменения через перехват page fault при попытке записи.
> Хотя модулем такое сделать скорее всего не получится.
Ви таки хотите поломать нашу любимую машину Тьюринга? И добавить туда блекджека и ...
| |
|
|
|
2.30, Michael Shigorin jolla (?), 16:41, 30/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> хренью занимаются..
Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(
но вот что мешало помолчать или спросить?..
| |
|
3.40, pavlinux (ok), 23:51, 30/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> хренью занимаются..
> Вы, как обычно, не обладаете даже квалификацией для понимания ее недостатка :(
> но вот что мешало помолчать или спросить?..
Всё нормально, мы для таких и работаем.
| |
3.43, Аноним (-), 00:04, 31/01/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
недостаток очевиден:
медной проволокой прикрутили костылище..
вполне себе обыкновенный антиметирн под названием "Katamari"..
вот так стало тебе легче понять фразу "занимаются хренью"?
| |
|
|
1.14, Аноним (-), 13:07, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> для противостояния эксплоитам для ещё неизвестных уязвимостей, если в них не применяется специальных мер для обхода LKRG
Ну то есть всё как обычно. Если эта штука станет достаточно распространена, её быстро научатся обходить, и даже авторы этого не отрицают.
| |
1.16, Аноним (-), 13:32, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> Openwall
> защиты от эксплуатации уязвимостей в ядре Linux
Неудачное название для такого класса проектов, — "открытая стена".
| |
|
2.19, Andrey Mitrofanov (?), 13:44, 30/01/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
>> Openwall
>> защиты от эксплуатации уязвимостей в ядре Linux
> Неудачное название для такого класса проектов, — "открытая стена".
Окна(tm)(R)(sm) -- лучше?
| |
|
3.23, pavlinux (ok), 15:18, 30/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> Openwall
>>> защиты от эксплуатации уязвимостей в ядре Linux
>> Неудачное название для такого класса проектов, — "открытая стена".
> Окна(tm)(R)(sm) -- лучше?
Солнышко, Яблоко, Дурдом Ромашка, Конц. лагерь Огонёк. ...
| |
|
2.26, solardiz (ok), 15:40, 30/01/2018 [^] [^^] [^^^] [ответить]
| +4 +/– |
>> Openwall
>> защиты от эксплуатации уязвимостей в ядре Linux
> Неудачное название для такого класса проектов, — "открытая стена".
По-моему, наоборот очень удачное. У нас motto - "bringing security into open environments" - то есть мы обеспечиваем безопасность в открытых системах, почти без снижения их доступности для пользователей. На момент выбора названия (1999 год), была тенденция у веб-хостеров отнимать у пользователей доступ к Unix shell (при этом реально безопасность, может быть, и не повышая - всё равно давался FTP-доступ для размещения едва ограниченных PHP-скриптов). Мы так не хотели, поэтому занялись созданием такого дистрибутива где с приемлемым уровнем риска можно давать доступ в shell. Тенденция с тех пор переломилась, но смысл названия остался, он по-прежнему актуален, и к нему еще можно добавить то что мы не преувеличиваем уровень безопасности наших разработок - что особенно хорошо видно как раз в данном анонсе LKRG.
| |
|
1.20, Нанобот (ok), 14:30, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
| |
|
2.25, solardiz (ok), 15:27, 30/01/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
> жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG называем integrity checking, и не включает то что мы называем exploit detection.
А чем именно "жалкое", кроме как датой появления?
| |
|
3.42, pavlinux (ok), 23:54, 30/01/2018 [^] [^^] [^^^] [ответить]
| +2 +/– |
>> жалкое подобие Windows PatchGuard (первые версии которого появились более десяти лет назад)
> Аналогия уместна, но по-моему она ограничивается тем что мы в анонсе LKRG
> называем integrity checking, и не включает то что мы называем exploit
> detection.
> А чем именно "жалкое", кроме как датой появления?
Нельзя защищать то (от того), чего еще нет. :)
| |
|
|
1.21, Ананас (?), 14:52, 30/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
Лет 10-12 назад проблема достойно решалась использованием LIDS.
Теперь вариант с LKRG...
Все вращается по кругу.
| |
|
2.24, solardiz (ok), 15:19, 30/01/2018 [^] [^^] [^^^] [ответить]
| +3 +/– |
По-моему, общее с LIDS здесь только то, что в новости в последней фразе последнего абзаца - "Отдельно развивается расширенный вариант модуля, в котором предоставлены дополнительные опции для защиты процессов, файлов и логов" - что в переписке с Адамом (автор LKRG) я называю BSD securelevel on steroids, и что мы сами в нынешний анонс даже не включали (кроме как через ссылку на wiki, где это есть). Это имеет мало общего с той функциональностью, которую мы анонсировали сейчас, и будет ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем, где даже обновления ядра вовремя не ставятся (или перезагрузка в новое ядро делается не сразу), в то время как разумное применение подобия securelevel требует нетривиальной настройки и последующего внимания.
| |
|
3.55, ПавелС (ok), 14:28, 31/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
>[оверквотинг удален]
> предоставлены дополнительные опции для защиты процессов, файлов и логов" - что
> в переписке с Адамом (автор LKRG) я называю BSD securelevel on
> steroids, и что мы сами в нынешний анонс даже не включали
> (кроме как через ссылку на wiki, где это есть). Это имеет
> мало общего с той функциональностью, которую мы анонсировали сейчас, и будет
> ориентировано (если вообще будет) на другой круг пользователей. Анонсированный сейчас
> основной проект LKRG наиболее актуален для типичных дистрибутивов и "заброшенных" систем,
> где даже обновления ядра вовремя не ставятся (или перезагрузка в новое
> ядро делается не сразу), в то время как разумное применение подобия
> securelevel требует нетривиальной настройки и последующего внимания.
BSD securelevel результат тяжёлой паранойи поверьте мне. Ум рассматривал ситуацию когда в системе два рута он и хакер и решил зацепиться за отключение двух капабилитисов.
| |
|
|
|
2.38, Michael Shigorin (ok), 23:09, 30/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А я сказал: "Вот и на Linux появился антивирус"!
> Шо за цензура на ресурсе?
Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...
(но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту не хватает квалификации даже понять это)
| |
|
3.47, VINRARUS (ok), 04:20, 31/01/2018 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> А я сказал: "Вот и на Linux появился антивирус"!
>> Шо за цензура на ресурсе?
> Похоже, кто-то из коллег-модераторов или даже скрипт-автомодератор счёл, что эта истерика
> нарушила что-нить вроде п.6 http://wiki.opennet.ru/ForumHelp ...
В чом истерика то? Обычная констатация факта. А аргументы в новости написаны: "Модуль подходит как для организации защиты от уже известных эксплоитов для ядра Linux, так и для противостояния эксплоитам для ещё неизвестных уязвимостей"
> (но сказали-то всё равно глупость -- Вам, как и ув. Xasd, попросту
> не хватает квалификации даже понять это)
И чем принципиально отличается этот модуть от антивируса?
| |
|
4.53, Аноним (-), 11:19, 31/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
>> чем принципиально отличается этот модуть от антивируса?
Ну наверное тем, что как раз вирусы-то он и не ловит.
| |
|
5.61, VINRARUS (ok), 20:40, 31/01/2018 [^] [^^] [^^^] [ответить]
| –4 +/– |
>>> чем принципиально отличается этот модуть от антивируса?
> Ну наверное тем, что как раз вирусы-то он и не ловит.
Как будто антивирус их ловит. ;D
| |
|
|
|
|
1.50, Аноним (-), 09:02, 31/01/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?
| |
|
2.54, Аноним (-), 12:15, 31/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
> solardiz, если кто-то добьётся rce в режиме ядра, то что ему помешает
> найти вашу таблицу с хешами и поместить туда новый пересчитанный хеш?
Если кто-то добьётся RCE на уровне ядра, то зачем ему что-то менять, когда RCE уже получен:-) LKRG и нужен, чтобы RCE не случился.
| |
|
3.62, Аноним (-), 22:01, 31/01/2018 [^] [^^] [^^^] [ответить]
| +/– |
Вообще-то я спрашивал solar designerа.
Имхо тут 2 варианта.
1 проверка происходит до того, как атакующий обошёл защиту памяти. Тогда структуры неповреждены и проверка ничего не выявляет.
2 проверка происходит после модификации памяти атакующим на уже скомпромитированной системе. Раз атакующий может модифицировать память, то он может пересчитать хеши записать их куда надо. Проверка опять ничего не выявляет.
| |
|
4.63, solardiz (ok), 22:45, 31/01/2018 [^] [^^] [^^^] [ответить]
| +1 +/– |
Во-первых, мы сразу позиционируем LKRG как bypassable by design и как предоставляющий лишь спорную security through diversity. Именно об этом говорится в анонсе по ссылке из новости здесь.
Во-вторых, с другой стороны, не каждая уязвимость в ядре и не каждый ее exploit приводит именно/сразу к RCE. Возможны ситуации, когда атакующему доступна попытка записи от имени и в адресное пространство ядра с какими-либо ограничениями или доступны лишь отдельные bit flips (как в случае с Rowhammer). В этих случаях у LKRG есть шанс (но не гарантия) распознать проблему до того как атакующий выполнит следующие шаги атаки.
В-третьих, из-за LKRG exploit'ы могут усложняться, а их надежность снижаться. В приведенном примере с пересчетом хешей, потребуется сначала найти их и ключ для SipHash (который генерируется случайно при загрузке модуля). Думаю, сейчас это, уже имея RCE, сделать не сложно - мы пока не пытались скрыть расположение этих переменных. Также, думаю есть более простые и надежные способы обхода текущей версии LKRG. Мы пока не решили будем ли развивать проект в сторону борьбы с обходами (чтобы повысить сложность и снизить надежность exploit'ов всё равно обходящих LKRG) или же, наоборот, решим еще более ограничиться security through diversity (позволяя любому желающему легко и надежно обходить LKRG, но зато упростив и сделав более быстрым и надежным код LKRG). Может быть, это будут две ветки разработки.
| |
|
5.67, Аноним (-), 18:41, 02/02/2018 [^] [^^] [^^^] [ответить]
| –1 +/– |
Звучит очень разумно. Это не абсолютная защита, но подложить атакующим пару мин - идея хороша. Жаль что как обычно будет куском проблем в использовании и опять какие-нибудь скандалы с майнлайном выйдут. Хотя с такой защитой по другому сложно.
| |
|
|
|
|
1.65, Аноним (-), 14:00, 01/02/2018 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
А вот и антивирус, в pro версии видимо добавят сигнатуры эксплоитов ;-)
| |
|
2.68, Аноним (-), 04:49, 03/02/2018 [^] [^^] [^^^] [ответить]
| +/– |
Прежде, чем добавлять сигнатуры в Pro версию, надо убедиться, что те эксплойты обходят Free версию :-)
| |
|
|