Pull to refresh

Comments 24

Печально. Я ждал, так сказать, «немного» большего от SELinux, даже с «коробочными» настройками.
Я искренне надеялся на более «положительный» результат.
Но интерес был именно в таком «чистом» тесте. ПОсмотреть объективные результаты.
Интересно увидеть аналогичный тест с AppArmor.
Кстати действительно интересно. Самое главное что он гораздо менее геморный чем selinux, и его реально настроить для проекта. А вот насколько слабее пути чем контексты, это отдельный вопрос.
Установленный из коробки доставляет гемор с настройкой софта, а получается и пользы от него немного…
Как я и написал, скорее я выбрал не самый удачный пример.
Польза есть. Но, к сожалению, в других местах.
Для защиты от ошибок в коде следует применять Web Application Firewall
Вы абсолютно правы.
Не знаю, при чем тут котэ, но он зачетный!
UFO just landed and posted this here
Я тут ждал…
А Вашей статьей Вы только подтвердили, что selinux по дефолту надо выключать, ибо он несет много проблем при настройке ПО, а толку без настройки 0.
Кому надо, пусть настраивают.
Ну, не 0.
Но довольно мало с точки зрения уязвимостей уровня DVWA.
К сожалению, осветить ситуацию целиком не вышло, ввиду отсутствия критических уязвимостей в системе, которые можно было бы использовать.
Я надеюсь на более быстрый ответ от моего коллеги ki11obyte, если он помнит подробности пентеста.
Я не готов сказать сейчас, есть ли данная уязвимость на тех системах.
Прошу простить, но я уже дома и тестовые машины мне не доступны.
Мне доступна кружка с пивом и чипсы.
На тестовых машинах было ядро 2.6.18 (подтверждение есть на скриншотах). mempodipper там не подходит.
На сколько я вижу, то не должен сработать этот сплойт, потому что нельзя создавать сокет из под домена httpd_t. Да и su не должен пропустить. Ответ теоритический.
Для данного типа проникновения лучше запрещать исполнение скриптов из каталогов в которые можно загружать файлы. Это более простой и быстрый способ. SELinux хорош при обслуживании больших проектов, для глобального контроля безопасности. Настраивать каждый раз на маленьких проектах не всегда удобно (хотя желательно это делать).
Поимел много проблем с незапускаемостью, когда ставил Redmine под CentOS. Поэтому странно, что во всех вариантах шел запустился.
Покажите пожалуйста вывод ls -laZ hackable и ls -laZ hackable/uploads в вариантах с включенным SELinux.
На папке hackable/uploads должно быть httpd_user_script_rw_t — читать и писать файлы из скриптов. Скрипт шелла из такой папки запускаться не должен.

На strict-политике я ограничивал контекстом запуск скриптов из uploads.
Проблема, как я ее понимаю, именно в том, что веб-шелл подгружается через другой скрипт (инклюд), выполнение которого вполне легитимно.
Да, от инклюдов похоже не спасает.
Sign up to leave a comment.