> Всё зависит от того, как именно всё реализовано. Мы этих моментов не уточнили - я не понимаю, как тебе ответить: мы можем придумывать примеры и контрпримеры почти бесконечно.Например, переключатель может быть вообще исполнен в железе.
> Я не знаю, что именно там используется, но представить там PaX я вполне могу.
> > Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера.
> Што?
Есть общая теория проактивной защиты. Область применения: гарантии безопасности некретических для жизни человека, экологии, ... ИТ систем. Доступность сервисов в этой теории неважна, важны гарантии безопасности и недопущения вреда самой ИТ системе. Грубо говоря в этой теории выделяют 3 класса активной реакции системы на взлом:
1. Убить один процесс который нарушил определенные правила.
2. Убить все процессы некого пользователя и запретить создания новых процессов этому пользователю, который сильно нарушает правила.
3. Ядро OS убивает себя. В самой критической ситуации для предотвращения развития атаки ядро OS убивает само себя.
Пример реализации:
CONFIG_GRKERNSEC_BRUTE=y
CONFIG_GRKERNSEC_KERN_LOCKOUT=y
https://en.m.wikibooks.org/wiki/Grsecurity/Appendix/Grsecuri...
"If you say Y here, when a PaX alert is triggered due to suspicious
activity in the kernel (from KERNEXEC/UDEREF/USERCOPY)
or an OOPS occurs due to bad memory accesses, instead of just
terminating the offending process (and potentially allowing
a subsequent exploit from the same user), we will take one of two
actions:
If the user was root, we will panic the system
If the user was non-root, we will log the attempt, terminate
all processes owned by the user, then prevent them from creating
any new processes until the system is restarted
This deters repeated kernel exploitation/bruteforcing attempts
and is useful for later forensics."
Для админа это очень важно понимать!!!
Вот пример: по соседству https://www.opennet.ru/openforum/vsluhforumID3/119792.html#146
он думает что Linux capabilities и DAC это одно и тоже. На практике будет тоже что с умершим в больнице пациентом: в случае запрета доступа DAC прога получает просто Access denied от ядря и может его обработать, а в случае нарушения capabilities проактивное ядро OS этот процесс убет.
> > > Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?
> > Тогда виноват не админ с PaX а программист...
> За падение даже куда менее критичных сервисов админ, работающий на вменяемую компанию, обычно получает конкретный втык.
> ... И перевод стрелок тут не прокатит.
За баг в программе отвечает програмист, тестер, а не админ. Админ может только поймать баг и написать по этому поводу рапорт. Да, резервирование, мониторинг и подем упавших сервисов, минимизация/исключение времени простоя - дело админа.
> не понятно, почему в падении из-за бага (т.е. без внешнего злонамеренного воздействия) виноват программист, а в падении из-за уязвимости - администратор.
Если падение из-за бага программы виновны однозначно только разработчики программы.
Если падение вызвано активной реакцией ядра OS на попытку эксплуатации уязвимости, то уже могут быть виновны не только програмисты, написавшие уязвимый код. В этом случае есть действие админа который установил проактивную защиту ядра OS. И если проактивная защита была установлена в системе, для которой предоставление сервиса более важно чем ее безопасность, то это уже вина админа.
Если код уязвим и идет вирусная атака, то в случае дешовой проактивной защиты, сервис будет недоступен даже с резервированием и защитой от сбоев. В этом случае для гарантии доступности сервиса приходится применять более дорогие средства защиты и обязанность админа их применить.
