CentOS + интересная задача + /tmp (noexec)

а что плохого в запущеном каком то левом перл-процессе горе-кулхацкера при нормально настроеных лимитах в системе и правах на безопасность ? разве что трафика может на генерить - что конечно тоже не есть хорошо.

метод решения "влоб":

переименовать perl во чтото типа /usr/bin/MySuperPerl и клиентам, которым он действительно необходим - выдавать этот путь. в своих служебных скриптах, типа сбора статистики, mysqltuner - прописать этот путь, благо - скриптов таких с десяток, не больше.

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

Разошлет спам, побрутфорсить сервера вокруг - схлопочите абузу и если вы в hetzner'e понятное дело чем это кончится.

И /tmp в /permaтent :)

А касательно решения - сложно это, потому что подразумевается, насколько я понимаю, что товарищ уже получил root доступ. И думать о том как же мне спастись от того, что он зайдет по SSH под root-ом и сделает perl a.pl ... :)

Тут помочь могут только selinux/grsec, чтобы спастись от взлома через работающие от root-а сервисы. После логина через SSH вы висите в несконфигурированном окружении и можете все. Поэтому тестировать на SSH смысла нет.

Если на файле права не выше положенного, а для перла это 700, то ничего пользователь не запустит из /tmp

WapGraf, а как же CGI?

[umka], что CGI?

Извините, не понял.

Кто положил на perl права 700? 😮

Пользовательские CGI-скрипты могут захотеть выполнить Perl/Python/Ruby. PHP Вы им тоже запрещаете?\

Вариант с SElinux и прочими не сработает -- perl'у можно запихнуть скрипт в stdin, а запрещать perl-процессу читать stdin нельзя, так как он только этим и занимается обычно :)

Не на бинарник, а на любой пользовательский скрипт. Да и на многих системах при 755 скрипт выдаст error. А 700 безопасный, даже без noexec, потому что прав выполнить скрипт у другого пользователя нету, права только у владельца.

Ну, тут вроде разговор про уязвимую папку /tmp речь шла исключительно.

Может быть просто chroot ... 😕

Glueon - перечитайте что я написал, причем тут root ?

WapGraf - или я что-то не понял или вам тоже перечитать надо, клиент заходит например в ssh (который доступен) или заливает через веб файлик в /tmp, а потом его выполняет из под себя или из под апача... Ваш пример не совсем поясняет что произошло, я могу сейчас предположить в /tmp лежит файлик a.pl который принадлежит руту, так че вы его от юзера запускать пытаетесь?

Boris A Dolgov - а у вас какие есть предложения по сути вопроса?

Romka_Kharkov, я описал конкретно только про perl, который упоминался ранее.

Возможно я и неверно понял суть задачи. Как правило с помощью noexec защищают временную директорию сервера, а не пользователя. Я так понял что речь идет об опасности, что пользователь может запускать не свое.

На каждого пользователя создавать noexec?