Удаление gcc в целях безопасности

[-sanches-]

Вроде как рекомендуют. Удалил на сервере. Перестал работать eix, т.к. не стало библиотеки libstdc или как-то так. Собственно, на сколько верно удаление гцц при таком раскладе? Ведь может еще что-то перестало работать.

[Black]

Врут. Для пущей безопасности надо удалить glibc и ядро.

[deadhead]

Hardened Gentoo

[/dev/random]

Собственно, на сколько верно удаление гцц при таком раскладе?

Абсолютно НЕВЕРНО. Единственное, чем может повредить gcc - это тем, что злоумышленник, получив права непривилегированного пользователя, сможет собрать какой-нибудь эксплойт. Однако на деле их гораздо чаще собирают у себя и кидают жертве уже бинарными. Поэтому для защиты от подобных вещей нужно не gcc удалять, а монтировать все публично доступные на запись разделы как noexec.

[NickLion]

Ого как радикально. Хотя бы права на запуск GCC от непривилегированного пользователя отобрали, если уж так хочется, но удалять-то зачем.

[drBatty]

Вроде как рекомендуют.

ну если вы перед этим уже всё сделали (список очень длинный... mount noexec всё, всё в chroot, запрет ВСЕМ и ВСЮДУ, в т.ч. и руту... И прочие мероприятия, к примеру автоматчики по периметру...), тогда просто удалите все бинарники gcc. и все ненужные либы.

Ведь может еще что-то перестало работать.

значит вы неправильно подошли к проблеме - работать должно перестать ВСЁ. а потом каждый бинарник надо отдельно включить ручками.

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

[t.t]

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

Весьма наглядная параллель.

[-sanches-]

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

[broom]

Я может сейчас глупый вопрос задам, но всё-таки...
Вернуть-то gcc теперь можно? emerge работать не перестал (чтобы бинарный пакет поставить)?

[t.t]

Я может сейчас глупый вопрос задам, но всё-таки...
Вернуть-то gcc теперь можно? emerge работать не перестал (чтобы бинарный пакет поставить)?

Предполагаешь, что удаление gcc в генте это аналог проблемы chmod a-x $(which chmod)? (:

[broom]

Это значит, что "всё нормально, gcc обратно поставить можно"? :)

upd. Ну хотя можно же взять бинарный пакет и просто распаковать tar'ом.

[/dev/random]

Бинарные пакеты (если создавались) можно установить без gcc. Если же бинарных пакетов нет, можно выдрать gcc из стейджа.

[-sanches-]

Я может сейчас глупый вопрос задам, но всё-таки...
Вернуть-то gcc теперь можно? emerge работать не перестал (чтобы бинарный пакет поставить)?

Emerge продолжает работать.

[xorader]

буду немногословен:

[serzh-z]

Слов нет...

Собственно, на сколько верно удаление гцц при таком раскладе?

Вполне верно, если это столь необходимо.

[polovinamozga]

Почитал и посмеялся.
Сам когда-то года два назад в целях эксперимента удалил gcc и тоже наслушавшись про "безопасность".
Вернуть можно сделав шрут и распаковав заново стейдж.

[xorader]

Почитал и посмеялся.
Сам когда-то года два назад в целях эксперимента удалил gcc и тоже наслушавшись про "безопасность".
Вернуть можно сделав шрут и распаковав заново стейдж.

... или попросить добрых людей .tbz2-файл сделать с gcc

[sspphheerraa]

gcc - системный пакет, а для всех системных пакетов рекомендуется делать .tbz2
(можно, чтоб это делалось автоматом - FEATURES="buildsyspkg")

[taaroa]

Ого как радикально. Хотя бы права на запуск GCC от непривилегированного пользователя отобрали, если уж так хочется, но удалять-то зачем.

С помощь какого "инструмента" вы "права на запуск GCC от непривилегированного пользователя отобрали"?

Мне известен только один надежный (unbreakable): RBAC.

[sspphheerraa]

С помощь какого "инструмента" вы "права на запуск GCC от непривилегированного пользователя отобрали"?

Обычный chmod ...не?
Кому разрешено читать/запускать, тот пользуется, а кому запрещено - "command not found"

[NickLion]

С помощь какого "инструмента" вы "права на запуск GCC от непривилегированного пользователя отобрали"?

Мне известен только один надежный (unbreakable): RBAC.

Ну да, sspphheerraa прав, имелся в виду обычный chmod. Или setfacl. А что Вы подразумеваете под надёжным?

[taaroa]

С помощь какого "инструмента" вы "права на запуск GCC от непривилегированного пользователя отобрали"?

Мне известен только один надежный (unbreakable): RBAC.

Ну да, sspphheerraa прав, имелся в виду обычный chmod. Или setfacl. А что Вы подразумеваете под надёжным?

Просто рассмотрел возможные модели угрозы и составил модель нарушителя, вывод написал выше.
Если в систему уже проникли, а это следует из условия задачи, то запрет исполнения GCC от непривилегированного пользователя нарушителя от дальнейших действий не остановит.
Если "на локалхосте только я", то тем более, манипуляции сии с правами мне непонятны.
Товарищ deadhead еще в самом начале данной тему дал правильную ссылку...

P.S. да, это правда, не очень то доверяю продуктам от {RH,Novell,etc} и их возможностям, но разговор сейчас не об этом, речь о том, что в Gentoo только Hardened профили _рекомендованы_ для сервера.
P.P.S. еще можно сделать так: сборочный сервер, он же тестовый стенд, все остальные машины без компиляторов, настроены на использование готовых бинарных пакетов, как в традиционных дистрибутивах.
P.P.P.S. а еще можно сделать так... и так... и эдак... вопрос в том, действительно ли это необходимо с учетом затрат (человеческий и машинный ресурс) и решаемых задач.

[/dev/random]

Если уж взломщику так приспичит использовать gcc на взломанной машине (что сомнительно), он всегда сможет его просто туда закачать. Куда-нибудь в домашний каталог, и прописать $PATH. Так что, как я уже сказал, единственной защитой от подобных вещей является не удаление gcc, а монтирование всех доступных простым юзерам на запись разделов как noexec.
А тому, кто первым придумал эту идиотскую идею удалять gcc, нужно надавать по тому месту, которым он в это время думал. Т.е. под зад коленкой.

[sspphheerraa]

но ведь тогда юзер не сможет запускать и свои "легальные" приложения

[/dev/random]

но ведь тогда юзер не сможет запускать и свои "легальные" приложения

Легальные приложения - это те, которые поставил администратор. Их он запускать сможет.

[taaroa]

но ведь тогда юзер не сможет запускать и свои "легальные" приложения

Лично меня этот и ему подобные трюки не остановят, да.

Поехали

Код: Выделить всё

# mount | grep sdb6
/dev/sdb6 on /media/sdb6 type ext4 (rw,noexec,nosuid,nodev,noatime,user_xattr)
$ cat /media/sdb6/gcc_out.sh
#!/bin/sh
CFLAGS=`grep 'CFLAGS=' /etc/make.conf|awk -F\" '{print $2}'`
gcc $CFLAGS -E -v - </dev/null 2>&1 | sed -n 's/.* -v - //p'
$ /media/sdb6/gcc_out.sh
zsh: Отказано в доступе: /media/sdb6/gcc_out.sh
$ echo 'hah, noexec (;'
hah, noexec (;
$ cat /media/sdb6/gcc_out.sh|bash
-D_FORTIFY_SOURCE=2 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=k8 -fno-strict-overflow -mmmx -msse -msse2 -msse3 -mssse3 -m3dnow -mfpmath=sse -Wno-all -fPIE -O2 -fstack-protector-all

[mixrin]

Хитро

[/dev/random]

Лично меня этот и ему подобные трюки не остановят, да.
Поехали
/***/

Этот трюк давно известен. Но в том-то и дело, что скрипты могут навредить только если их удастся прописать в автозапуск. В .bashrc, к примеру. Против этого есть давно известная защита: принадлежащий руту публично-читаемый .bashrc; принадлежащий руту, но полностью доступный пользователю домашний каталог и sticky-бит на нём. Таким же способом нужно защитить другие автоматически выполняемые скрипты.

А для применения локальных эксплойтов, как правило, нужен бинарник. Бинарники на noexec-разделе не запустятся.