The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Уязвимость в гипервизоре VMM, развиваемом проектом OpenBSD"
Отправлено Дон Ягон, 05-Мрт-20 17:06 
>> Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например.
> А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется?

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

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

Я не знаю, что именно там используется, но представить там PaX я вполне могу.

> Смотри на ситуацию вирусной атаки

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

>> Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?
> Тогда виноват не админ с PaX а программист...

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

> Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера.

Што?

> Общее правило: проактивные системы защиты, которые убивают процессы, нельзя использовать в системах критических для жизни людей, экологии, производства ИТП...

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

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру