LINUX.ORG.RU
ФорумTalks

Установчные скрипты в rpm/apt-пакетах


0

0

Вчера немного увлекся одним флудом по ссылке, хочу услышать мнение по вопросу, который в принципе давно сидел в голове.

Если не ошибаюсь, в rpm или apt пакеты можно встраивать какие-то установочные скрипты, которые например смогут сгенерировать какие-нибудь первоначальные системные конфиги.

Вопрос в том, насколько эти скрипты могут быть потенциально опасны. Если они запускаются менеджером пакетов, то получается, что они выполняются автоматически в рамках команды вида «rpm -i package.rpm» от имени рута.

Получается, что я могу создать простой пакет, в котором в инсталл-скрипте будет команда «rm -rf» и его установка моментально угробит мне систему. Или пакет, который инсталл-скриптом внедрит мне вредоносный код во все исполняемые файлы в /bin, ну или заменит их модифицированными версиями (проинсталлит руткит).

Понятно, что во втором случае просто так менеджер пакетов системные файлы не заменит на зараженные файлы из пакета, т.к. возникнут конфликты, но ведь есть команды cp/dd и т.п, которые могут вызываться из инсталл-скрипта и по сути смогут делать все что угодно с правами рута.

Или я чего-то не догоняю и на инсталл-скрипт накладываются специальные ограничения? Или может вообще никаких инсталл-скриптов нет и я их сам придумал?

★★★★★

Неужели вы не можете придумать больше способов сделать пакет, который угробит систему?

melkor217 ★★★★★ ()

> Или я чего-то не догоняю и на инсталл-скрипт накладываются специальные ограничения? Или может вообще никаких инсталл-скриптов нет и я их сам придумал?

Всё верно. В spec-файл можно прописать любой код, который выполнится с правами рута. Поэтому и придумано подписывание пакетов.

Relan ★★★★★ ()
Ответ на: комментарий от init_6

если что-то надо удалить в системе или там создать то песочница не спасет.

потому что пакету может быть нужно настроить другой пакет которого в песочнице нема :)

# апач + пхп.

Slackware_user ★★★★★ ()
Ответ на: комментарий от Slackware_user

ну «rm -rf» это классика - всем сразу понятно о чем речь

bender ★★★★★ ()
Ответ на: комментарий от Slackware_user

потому что пакету может быть нужно настроить другой пакет которого в песочнице нема :)

не нужно! а иначе в топку такие пакеты.

да и я о FEATURES=«sandbox» и о portage если чо.

init_6 ★★★★★ ()
Ответ на: комментарий от Slackware_user

>если что-то надо удалить в системе или там создать то песочница не спасет.

потому что пакету может быть нужно настроить другой пакет которого в песочнице нема :)

# апач + пхп.



в качестве начальной полумеры например можно было бы заставить принудительно перечислять список системных файлов, которые пакет планирует поменять

bender ★★★★★ ()
Ответ на: комментарий от Reset

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

Ну и для make/make install в общем случае прав рута тоже не нужно - ставить в / программы из исходников в rpm/apt-системах вообще моветон.

А вот rpm/apt без рута не поставится по определению.

bender ★★★★★ ()

Когда появится первый вирус, который заражает рпм/деб/тгз-пакеты? Если он случайно попадёт на какое-нибудь зеркало, то произойдёт массовое заражение.

Yareg ★★★ ()
Ответ на: комментарий от Reset

На моем ноуте - ничего, т.к я здесь один пользователь. А на домашнем компьютере, где сидит несколько пользователей, разница появляется - одно дело угробить только свою домашнюю папку, а другое дело - всех пользователей разом.

bender ★★★★★ ()
Ответ на: комментарий от bender

>А вот rpm/apt без рута не поставится по определению.

rpm установишь. Опция --root. Только в целевой папке должны быть удовлетворены все зависимости.

Yareg ★★★ ()

Смиритесь и признайте, что Ляликс такое же решето как и Винда, просто большие дяди-вирмейкеры им еще серьезно не заинтересовались.

Sociopsih ★☆ ()
Ответ на: комментарий от Yareg

спасибо, это хорошая опция. попробовал к ней добавить --nodeps, чтобы распаковала просто так, но выдало ошибку «error: Unable to change root directory: Operation not permitted» - видимо без минимальной системы в этом каталоге (типа sh и libc) ей все-таки не обойтись.

bender ★★★★★ ()

согласись, установка любого ПО может содержать в себе «зловредство» скажем так. В винде с этим борятся при помощи антивирусов. Даже если компилить из сырцов - кто их читает ? =)

Но с другой стороны, я недавно сидел в винде, вообще стремно было что-либо ставить после репов, которым более-менее я доверяю.

Если уж совсем туго, использовать jail\openvz для предварительной установки ПО.

А вообще напомнило топик: http://www.linux.org.ru/forum/talks/4704605

f3ex ★★ ()
Ответ на: комментарий от f3ex

> согласись, установка любого ПО может содержать в себе «зловредство» скажем так

Одно дело, если бы rpm просто раскидал файлы из архива по системным каталогам, а простой пользователь уже от своего имени бы запускал эти зловредные программы; совсем другое - в процессе самой установки на системе запускаются сторонние скрипты с правами рута и при этом никак не контролируются.

А вообще напомнило топик: http://www.linux.org.ru/forum/talks/4704605


с него все и началось :)

bender ★★★★★ ()
Ответ на: комментарий от bender

я понял о чем ты. К примеру, при установке деба запускается скрипт по изменению конфига sudo и sshd, какая-то система должна среагировать и запросить: «меняется системный файл другой программы, продолжить?»...

Тоже давно мучает этот вопрос.

f3ex ★★ ()
Ответ на: комментарий от f3ex

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

bender ★★★★★ ()
Ответ на: комментарий от bender

В развитии идеи - добавить к списку типов зависимостей между пакетами: «требует» (requires) и «хочет» (нестрогая зависимость - ключевое слово не знаю) добавить зависимость «влияет» (affects) - и в ее рамках перечислить списков файлов из целевого изменяемого пакета.

Тогда перед установкой будет четко видно, что пхп собирается немного подкорректировать апач - и это очевидно нормально, а если он замахнется на bash или kernel, то это серьезный звонок.

bender ★★★★★ ()
Ответ на: комментарий от Yareg

> Когда появится первый вирус, который заражает рпм/деб/тгз-пакеты? Если он случайно попадёт на какое-нибудь зеркало, то произойдёт массовое заражение.

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

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

Adjkru ★★★★★ ()
Ответ на: комментарий от f3ex

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

bender ★★★★★ ()
Ответ на: комментарий от bender

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

f3ex ★★ ()

Установка софта серьёзное действие и делает его root, а не мальчик с улицы.

tux2002 ()
Ответ на: комментарий от bender

> А вот rpm/apt без рута не поставится по определению.

Если ты параноик, используй --noscripts.

А вообще, проблема высосана из пальца - если ты делаешь пакет, то можешь поставить на зловредный бинарь suid, и game over.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Можно софт ставить в /usr/local под непривелигированным пользователем. Дело политики дистростроителя и нашего выбора. Бутут думать над этим - появятся альтернативы.

tux2002 ()
Ответ на: комментарий от tailgunner

>Если ты параноик, используй --noscripts

Я сам не параноик - ставлю пакеты из билд-сервиса не глядя, но это все до первого раза, «пока не началось». Не думаю, что в ближайшее время дойдет до того, чтобы использование --noscripts стало актуальным, но как вариант тоже неплохо.

можешь поставить на зловредный бинарь suid, и game over.


С одной стороны согласен, с другой - менеджер пакетов все suid'ы в пакете сможет проверить и опять до установки пакета выдать предупреждение в стиле антивируса типа «скорее всего эта программа хочет больше, чем ей положено». А скрипт по определению - черный ящик.

bender ★★★★★ ()
Ответ на: комментарий от tailgunner

А вообще, проблема высосана из пальца - если ты делаешь пакет, то можешь поставить на зловредный бинарь suid, и game over.

в пакеты openSUSE запрещено включать suid бинарники, это проверяется в процессе сборки в билдсервисе, это описано выше по ссылкам

если suid необходим, то нужно представлять пакет на рассмотрение командой безопасности

HighwayStar ★★★★★ ()

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

Yareg ★★★ ()
Ответ на: комментарий от bender

>Если ты параноик, используй --noscripts

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

bender ★★★★★ ()

Есть репозитории, где весь софт проверяется на эту тему. То есть если человек = !ССЗБ, то он ставит только пакеты с репозиториев, за редким исключением, исключения - с официального сайта программы || пакет/исходники, полученные напрямую от разработчиков. То есть такие проблемы могут возникнуть только в случае взлома репозитория, и то, это должно быть основное зеркало, с которым синхронизируются остальные. Иначе взлом легко обнаруживается. Соответственно, в принципе, достаточно держать несколько основных зеркал и сверять контрольные суммы и подписи с каждым из них.

unikoid ★★★ ()

После прочтения треда остро вспоминается Михаил и неправильные двери. Есть понятие сети доверия, если же вы не верите никому, анализируйте исходники самостоятельно (этим, например, занимается команда OpenWall).

undertaker ★★ ()

Да, скрипты есть. Да, они запускаются с правами рута. Всё верно, увы.

AITap ★★★★★ ()
Ответ на: комментарий от bender

> менеджер пакетов все suid'ы в пакете сможет проверить и опять до установки пакета выдать предупреждение в стиле антивируса типа «скорее всего эта программа хочет больше, чем ей положено». А скрипт по определению - черный ящик.

Ерунда. Если уж на то пошло, то даже скрипт можно пускать в чруте или bind mount'е, анализировать через strace, и делать вывод о безопасности :)

tailgunner ★★★★★ ()
Ответ на: комментарий от HighwayStar

> в пакеты openSUSE запрещено включать suid бинарники

Прекрасно, то есть рискуете только личными данными пользователя. А скрипты тоже запрещено?

tailgunner ★★★★★ ()
Ответ на: комментарий от Sociopsih

Примите таблеточку. Если вдруг, на зеркалах станут появляться массово пакеты с закладками, то все поголовно дистрибы будут требовать обязательной подписи и деанонимизации ментейнера. Так что примите таблеточку ещё раз.

ixrws ★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.