URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 135186
[ Назад ]

Исходное сообщение
"Проект OpenPaX развивает аналог механизмов защиты Grsecurity/PaX для ядра Linux"

Отправлено opennews , 31-Окт-24 09:37 
Компания Edera, развивающая решения для защиты инфраструктуры Kubernetes и AI-систем, представила проект OpenPaX, представляющий собой...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62143


Содержание

Сообщения в этом обсуждении
"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Афроним , 31-Окт-24 09:37 
Параноики напряглись.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 09:54 
а когда это они успели расслабиться, а?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 10:03 
Наверное, в прошлой жизни!

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено n00by , 31-Окт-24 12:19 
> Параноики напряглись.

Участники секты Свидетелей Тысячеглаза догадались, что их обнуляют, и принялись делать покерфейс.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Афроним , 31-Окт-24 12:40 
Гики сидят на коре дуба и в ус не дуют, а остальным придется изворачиваться.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 13:01 
Покерфейс - это интерфейс к Покеру?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено голос_из_леса , 31-Окт-24 14:33 
Это интерфейс поккера - face of pokker (devil). ))

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 16:25 
> Покерфейс - это интерфейс к Покеру?

Ну зот не к полупокеру.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено n00by , 01-Ноя-24 11:42 
Покерфейс - это когда ставки сделаны, у партнёров флешрояль, а эксперт невозмутимо заявляет "всем водки, всем икры! медведей сюда и цыганей -- бюджет всё равно не мой"

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Тысячеглаз рулез , 31-Окт-24 21:42 
Если выбирая сторону "сильных" думаешь, что так всегда будешь на коне, то нет, этим самым конём и будешь.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено n00by , 01-Ноя-24 11:38 
> Если выбирая сторону "сильных" думаешь, что так всегда будешь на коне, то
> нет, этим самым конём и будешь.

Откуда взялись кони? В народном творчестве "за морём тёлушка полушка...", а тут её бесплатно отдают.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Megacock , 31-Окт-24 21:43 
Принцип неуловимого Джо пока неплохо работает. Поставь любой дырявый linux/vpn/firewall/mongodb/ПО на java использующее Log4j в небольшую компанию и вопрос взлома откладывается на годы. Я редко патчу exim, у меня нет и десятка пользователей и спам-фильтра. Всю некондицию я банально отправляю в /dev/null. И работает. Уже лет 8-9 как. За это время в спам-репорт не пришло, ни уведомлений о том что ваш сервер в блэк-листах, ни одного abuse со стороны хостера. Один раз пришло письмо что хостер мной "недоволен". Но это быстро удалось опровергнуть - просто поискать свой адрес в "черных" списках и указать, что в списках подсеть /16, а не конкретно я. При этом большая часть подсети хостеру не принадлежит. Благо опыт исключения из блэклистов у меня богатый, я раньше администрировал корпоративный почтовик. Потому поиск причин много времени не занял.
Вишенка на торте. На том хостере, что пожаловался и почтовика-то не было, иначе последствия я бы раньше заметил в виде недоходящих писем или писем отправляемых в спам.
С другой стороны, вот пример атаки на относительно крупную компанию 1000-2000 рабочих мест разбросанных по сотням филиалов от 1-2 до 10 машин + 100 в центральном офисе + 10-30 в региональных + 40 серверов. Шифровальщик присланный в отдел кадров смог вывести из строя три компа у HR. Вот Win32.Kido был гораздо большей проблемой в нулевые. Но к моменту атаки домены и файловые серверы на samba +POS-терминалы на java+linux + мобильные терминалы на winCE, а будь там вся инфраструктура основана на современном MS?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено AlexYeCu , 01-Ноя-24 13:24 
>Принцип неуловимого Джо пока неплохо работает.

У меня ещё лет 20 назад логи тестовых веб-серверов были забиты запросами, направленными на попытку замены прошивки роутеров популярных моделей через уязвимости в вебморде и телнете. Это всё давно автоматизировано, никакого особого внимания привлекать не надо. Что до нужности: для добавления в ботнет годится — значит нужно.

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

Ещё помню, эта активность резко сошла на нет, когда египетское правительство из-за беспорядков в стране рубануло доступ населению.

Ещё лет 5 назад попытка выставить ненастроенный прокси в инет в течение 5 минут приманивала туда легион китайцев.

Так что принцип Джо давно уже не работает. Прмерно со времён изобретения ботов.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Megacock , 01-Ноя-24 22:03 
Боты ломятся за вполне определенными и легко эксплуатируемыми уязвимостями, как правило в web. exim уж точно не самая популярная цель в этом плане. Останавливаться и целенаправленно ломать его ботоводам не интересно, когда есть много других "вкусных" целей. Да и сама идея взлома VPS для ботнета, так себе - заметно, разве что командный центр разместить или сервер раздачи. По моим наблюдениям, никто даже нестандартные порты не сканирует:
1. Проверили web.
2. Если нет или быстро забанили, то проверили SSH или RDP.
3. Если та же песня с баном, то пошли дальше, может потом когда вернутся.
Притом там не то чтобы какие-то изощренные методы атаки, просто проверили уязвим ли web, и попробовали перебрать пароли. Все. Из всего перечисленного только RDP может проблем доставить, т. к. ддосится легко. При большой атаке не пускает владельца VPS. Нут так нечего выставлять наружу. Есть vpn, там пусть хоть обддосятся. Но не будут, много других легких целей.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Афроним , 01-Ноя-24 14:17 
Чел,вот зачем такую простыню писать? Читать устанешь.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Megacock , 01-Ноя-24 22:30 
"Чукча не читатель".

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Соль земли , 31-Окт-24 09:49 
Ну вот, теперь придётся ещё и OpenPaX отключать при каждой установке.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 10:02 
Похоже что авторы программы огорчились почему их бекдоров нет в ядре и решили сами их внедрить под предлогом борьбы с  другими бекдорами.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Жироватт , 31-Окт-24 10:33 
Пока их патчины не навязывают в глотку всем - любо.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 13:34 
Окно овертона, "тогда и поговорим", "а когда пришли за мной" и прочием мемы про то что сначала вроде прикол, а потом у тебя ютуб не грузится и ты ничего не можешь сделать.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 13:47 
> Окно овертона, "тогда и поговорим", "а когда пришли за мной" и прочием мемы про то что сначала вроде прикол,

Всегда прикол) Не вижу никакой причины не отпустить шутку черного юмора.

> а потом у тебя ютуб не грузится и ты ничего не можешь сделать.

Так он и не грузится потому что ты "ничего не делал")
От такие пироги с котятами.



"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 14:49 
Так то товарищ и говорит что не надо ничего делать потому что любо. Дальше давай думай сам. Разворачивай аналогию.  

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено YetAnotherOnanym , 31-Окт-24 16:18 
Так и замечательно, не будет больше выжирать в одно рыло всю полосу у провайдера.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 10:09 
А DRM будет?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 20:45 
> А DRM будет?

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


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 11:37 
> механизм W^X
> механизм эмуляции с функциями-трамплинами
> методы защиты могут нарушить нормальную работу JIT-компиляторов

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


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 11:48 
Согласен, нет бы сразу на расте и питоне писать

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Жироватт , 31-Окт-24 12:11 
128ядерный кластер с жидкостным охлаждением / 640 гигабайт рамы в домашнем ПК-балдёжнике точно хватит, чтобы запустить БЕЗОПАСНЫЙ стек от низкоуровнего БЕЗОПАСНОГО ассемблера до БЕЗОПАСНЫХ js-скриптов внутри интерпретатора внутри песочницы браузерного движка внутри контейнера внутри прозрачной виртуалки над интерпретируемым сервисом поверх БЕЗОПАСТНОСТНОГО и ВЕРИФИЦИРОВАННОГО микроядра, крутящегося поверх ещё более безопасного наноядра?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено n00by , 31-Окт-24 12:27 
Тут даже пожизненная кАмпЕляция в BHC-релизенгах не поможет.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 12:29 
Ого ты выдал! Прямо буллщит бинго.

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


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 13:38 
Вин 98 светили в локальную сеть годами. При том что была возможность с ними делать  через локальную сеть скажем так очень многое.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Pahanivo , 31-Окт-24 15:14 
ГыГы, а ты смешной. Тогда локальные сети были только в организациях - и чем там искать, когда файло и базы лежали на каком-нибудь новел-нетваре?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 13:04 
Про пикоядро забыл упомянуть.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 20:48 
> 128ядерный кластер с жидкостным охлаждением / 640 гигабайт рамы в домашнем ПК-балдёжнике
> точно хватит, чтобы запустить БЕЗОПАСНЫЙ стек от низкоуровнего БЕЗОПАСНОГО ассемблера
> до БЕЗОПАСНЫХ js-скриптов

А чего такое хилое то? Уже вон Ampere 192 и даже 256 ядер выкатили. Впрочем AMD тоже смогли столько в EPYC, хоть и "dense" огрызки урезаные. А у тебя 128 всего - фу, прошлый век.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено bdrbt , 01-Ноя-24 09:21 
В цитатник!!!

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено pavlinux , 31-Окт-24 20:22 
Через 10 лет закроются и будут продавать по 300.000$ за патч?

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 21:05 
Возможно, это их полное право.

Но
1 даже столлман говорил что GPL это не обязательно бесплатно
2 все десять лет потреблятели будут получать код нахаляву
3 весь код до смены лицензии останется открытым и пользователи смогли бы сами его развивать и дальше, если бы не были такими бесполезными


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 31-Окт-24 21:48 
> пользователи смогли бы сами его развивать и дальше, если бы не были такими бесполезными

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


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено pavlinux , 31-Окт-24 20:47 
Oй oтcтoй ....

1. добавим свой член в tasc_struct->mm_stuct:  current->mm->pax_flags

2. устанoвим фляг:

 
if (snapshot_randomize_va_space) {
        set_bit(PAXF_RANDMMAP, ¤t->mm->pax_flags);
}

3. Проверим фляг:
 
#ifdef CONFIG_OPENPAX
        && test_bit(PAXF_RANDMMAP, ¤t->mm->pax_flags)
#endif

Проверка флага в бинарнике ... parse_flag('r', 'R', PAXF_RANDMMAP);
Фляг в файл пишется естественно "своей новой" утилью (ниасилили objcopy)

Так работают все детские системки защиты.  :D


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Тролололо , 01-Ноя-24 14:45 
Ты просто не понимаешь о чём говоришь. Исключить выполнение для страниц доступных для записи и наоборот это must have.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено n00by , 01-Ноя-24 19:19 
Он не про это говорит, а про детали реализации того "must have".

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 01-Ноя-24 14:25 
> аналог набора патчей PaX от проекта Grsecurity, который с 2017 года поставляется только в составе платного продукта.

Ложь. Читаем пункт 2.B лицензии GPL-2 !!!
https://www.opennet.dev/openforum/vsluhforumID3/120167.html#80
https://www.linux.org.ru/forum/linux-hardware/7895968?cid=16...

> при маппинге страниц памяти механизма W^X (write XOR execute), не допускающем создание страниц памяти, одновременно доступных на запись и исполнение, а также блокирующем смену типа маппинга страниц с записи на исполнение.

Для обеспечения корректной работы ядра OS с памятью необходимо и достаточно:
  1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
  2. запрет изменения на запись памяти которая выделена как исполняемая (W^X),
  3. запрет создания исполняемой памяти из анонимной памяти (W^X),
  4. запрет изменения на запись памяти выделеной только для чтения (RELRO).
https://www.opennet.dev/openforum/vsluhforumID3/129886.html#312

Компилятор важен, но гарантии безопасности должны быть даны во время исполнения процом и ядром OS.
https://www.opennet.dev/openforum/vsluhforumID3/129886.html#310


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Тролололо , 01-Ноя-24 14:51 
>3. запрет создания исполняемой памяти из анонимной памяти (W^X),

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


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 01-Ноя-24 16:49 
>> 3. запрет создания исполняемой памяти из анонимной памяти (W^X),
> Это много где востребованно и должно быть

У меня в системе запрещено и нигде не используется. Писать правильно надо, чтоб дыр не было.

> Сразу видно человека далёкого от разработки ядра

Забросил лет 15 назад.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 01-Ноя-24 16:54 
> нужно ввести новую привелегию типа CAP_ANON_MAP_EXEC.

Все ПО обычного пользователя должно работать без привилегий.

Привилегии нужны не для раздачи их пользователям, а для понижения правилегий рутовых процессов до необходимого и достаточного минимума.
    # pscap
не должен выводить процессов с full привилегиями.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено мяв , 02-Ноя-24 09:42 
должно онониму с интернета?
>для понижения правилегий рутовых процессов до необходимого и достаточного минимума.

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

Вы переводчик неосилили, или слово "полными" уже немодное среди ононимов?
с "full привелегиями" работают только суиды и рутовые процессы. Вы вообще о чем?
о "не должно быть процессов с доп. возможностями"? ping google.com сделайте - сильно удивитесь. раньше он вовсе был суидным.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 02-Ноя-24 20:24 
https://www.opennet.dev/openforum/vsluhforumID10/5622.html

CAP не для раздачи привилегий процессам пользователя, а для ограничения привилегий рутовых процессов до необходимого и достаточного минимума.

Да, ping должен иметь привилегию net_raw для создания сокета, но он ее должен сразу сбросить. И раздача, и контроль за привилегиями должен быть https://www.opennet.dev/openforum/vsluhforumID10/5622.html#8

У меня в системе pscap не показывает процессов с full приведениями, все процессы, включая матовые, ограниченные до необходимого и достаточного минимума с гарантией невозможности повышения своих привилегий.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено мяв , 02-Ноя-24 23:43 
>https://www.opennet.dev/openforum/vsluhforumID10/5622.html
>>чтобы root его запускал и процесс имел пониженные привилегии

сами решили свою неграмотность показать?
возможности(caps) нужны что б приложениям, вместо суида, давать огран. к.-во привелегий. не для "понижения привелегий рута".

>https://www.opennet.dev/openforum/vsluhforumID10/5622.html#8
>>Мое мнение:

Вы, наверно, очень удивитесь, когда узнаете, что "разработчики дистрибутива" заранее не знают, что Вы ставить будете и как юзеров назовете.
если посмотрите чуть внимательнее - заметите и отсутствия условной "capabilities.conf.d"  .. как предложите при удалении пакета, удалять разрешения? файл post-rm  скриптами парсить?

>включая матовые

даже спрашивать не буду.
тем не менее, Вы адекватное что-то по поводу идеи анонима выше так и не смогли - его подход более, чем рационален.
"вместо того, чтобы давать доступ к потенциально небезопасной операции всем, давать его по атрибуту бинарника".
lsm, вроде SARA, делают это так же. только там не cap, а обычный атрибут.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 03-Ноя-24 09:11 
CAP разработан в конце 1970-тых, начала 1980-тых для UNIX как расширение безопасности MULTICS, который определял только DAC и MAC. Назначением CAP есть понижение привилегий рутовых процессов до необходимого и достаточного минимума. Требование наличие CAP в OS юридически закреплено в описании уровня B3 "Оранжевой книги".

CAP как побочные эффект, в GNU/Linux адаптирован не только для понижения рутовых привилегий, но и для раздачи привилегий пользовательским процессам. Например ping можно дать привилегию net_raw, но при этом надо проверить код ping и проконтролировать сбрасывает ли ping привилегию сразу после открытия сокета! Для контроля раздачи привилегий пользователям есть файл: /etc/security/capability.conf в котором админ прописывает какой пользователь, какие привилегии имеет право унаследовать.
https://www.opennet.dev/openforum/vsluhforumID10/5622.html#8
При удалении бинаря с атрибутом CAP с системы пользователь не будет иметь возможность повысить привилегию процесса. Потому что для создания процесса с привилегией, лично я предлагаю требование наличия двух условий: явного права пользователя наследовать некую привилегию и наличие возможности унаследовать эту привилегию в CAP атрибуте конкретного бинаря.
В CAP атрибуты бинарей прописываю "i", а не "ep", а в /etc/security/capability.conf право пользователей наследовать привилегии.

У меня в системе pscap не показывает процессов с full привилегиями, все процессы, включая рутовые, ограниченные до необходимого и достаточного минимума с гарантией невозможности повышения своих привилегий.


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 04-Ноя-24 09:04 
> с "full привелегиями" работают только суиды и рутовые процессы.

С full привилегиями в системе не должен работать ни один процесс! pscap не должен показывать процессов с full привилегиями.

В GNU/Linux  есть возможность раздавать и отбирать привилегии у пользователей и процессов, оставляя им лиш необходимый и достаточный минимум привилегий. Например у меня пользователь root (USERID=0) везде лишён привилегии net_raw и пингануть не может!!! А пользователь admin (USERID=1000) имеет возможность пользоваться привилегией net_raw при запуске утилиты ping...


"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено Аноним , 06-Ноя-24 17:21 
Ещё добавлю, что если у пользователя root отнять привилегии, то при рестарте под рутом некого сервиса ему может не хватить привилегий для запуска и работы. Для этого надо или оставить руту много привилегий или предварительно позаботится о возможности рестарта сервисов с нужными им привилегиями при сильно ограниченном пользователе root.

"Проект OpenPaX развивает аналог механизмов защиты Grsecurity..."
Отправлено pavlinux , 18-Ноя-24 18:46 
>   Для обеспечения корректной работы ядра OS с памятью необходимо и достаточно:
>   1. запрет изменения на исполняемую области памяти которая исполняемой не создавалась (W^X),
>   2. запрет изменения на запись памяти которая выделена как исполняемая  (W^X),
>   3. запрет создания исполняемой памяти из анонимной памяти (W^X),
>   4. запрет изменения на запись памяти выделенной только для чтения  (RELRO).

Как это связано с "корректной работой ядра OS с памятью"?