проблема безопасности параметра AllowKey=system.run у агента

[lll]

Параметр AllowKey был введен, как я понимаю, чтобы администраторы сервера Zabbix не могли выполнять что угодно на наблюдаемом хосте.
Однако вызов команды происходит через шелл, а не exec-ом, поэтому при ограничении AllowKey=system.run[/path/to/script *,*] возможно со стороны сервера вызвать команду "/path/to/script ; another command" для выполнения произвольного кода.
Если задать AllowKey=system.run[/path/to/script,*], то проблема с безопасностью уйдет, но зато станет невозможно передавать параметры скрипту.

[lll]

Что-то нет никаких откликов по проблеме...
До того, как писать сюда, хотел запостить bug report, но испытываю трудности с изложением на англицком.
Начал составлять текст, но залип на согласовании времен и забросил это занятие :-(
Не задвинет ли кто-нибудь это в поддержку Заббикса?

В дополнение сообщаю, что было проверено в версиях агента 5.0 и 6.4.

Предложение по исправлению:
1) звездочки в таком качестве, как сейчас, не поддерживать в первом параметре system.run при использовании в AllowKey;
2) если первым символом после "[" стоИт "^", то воспринимать первый параметр как регулярное выражение, иначе как простую строку.

[teddy]

IMHO задача почти не решаема в принципе в данном контексте.
Если вы всерьез заботитесь о безопасности - то надо либо вообще закрывать возможность запуска system.run, либо разрешать запуск строго описанных скриптов либо программ без всяких параметров, выполняющих однозначные действия. Любой другой вариант всегда оставляет шанс комбинацией параметров ли, перенаправлением ввода\вывода ли, что то еще придумают, заставить систему на стороне клиента вести себя не штатно и выполнить некое небезопасное действие.
Может помогло б запуск того что в system.run от имени другого пользователя с минимальными правами, но тогда появляется проблема сохранения или передачи пароля к такому пользователю.

[Kos]

Предложение по исправлению:

Когда только вводилась эта "фича" (т.е. возможность более гранулярно ограничивать разрешённые метрики, в частности - выполняемые команды), то на посвящённом этому вебинаре я задавал вопрос: зачем для этого был выбран такой синтаксис, не проще ли было использовать регулярные выражения (тем более, что их поддержка на стороне агентов к тому моменту как раз была официально закреплена на уровне pcre). Ответ был - исключительно по соображениям эффективности (т.е. скорости работы). Регулярные выражения - вещь мощная, но (при использовании более-менее навороченных выражений), к сожалению, не быстрая. А в данном месте скорость проверок крайне важна, т.к. работающий в пассивном режиме агент должен проверять каждый входящий запрос.

[lll]

Когда только вводилась эта "фича"...

Так себе аргументация.
Можно в документации предупредить пользователя насчет рисков для эффективности при использовании RE и рекомендовать воздерживаться от них в тех случаях, когда ограничиваемый элемент дёргается достаточно часто.
Если system.run используется как действие на срабатывание триггера, то он вряд ли часто вызывается. Конкретно в нашем случае это 2-3 раза за 5 месяцев.
В любом случае "*" в AllowKey из соображений безопасности как минимум на пару порядков хуже, чем возможность при желании прибегнуть к RE.
Такую фичу надо выпилить однозначно, даже не раздумывая.
При этом ничего не потеряется в части функционала, если ввести RE, т.к. конструкция [command *] легко заменяется на [^command ] (простейшее выражение, поэтому вычислительную нагрузку не несет).
Правда, синтаксис в части ограничителей RE надо еще продумать, т.к. у system.run есть второй параметр.

[lll]

IMHO задача почти не решаема в принципе в данном контексте.

С чего это она не решаема? Несложные регулярные выражения прекрасно справятся с ограничениями, допускающими только параметры скрипта и ничего более.
Полный запрет на использование параметров лишает нас возможности передать скрипту имя объекта, нуждающегося в устранении проблемы.
Перечисление в конфиге всех возможных объектов (по одному AllowKey на каждый) не поможет при использовании обнаружения.

[Kos]

воздерживаться от них в тех случаях, когда ограничиваемый элемент дёргается достаточно часто.

Читаем ещё раз, внимательно:

работающий в пассивном режиме агент должен проверять каждый входящий запрос

Параметры AllowKey/DenyKey влияют на все метрики. При работе в пассивном режиме каждый входящий запрос должен быть проверен на соответствие ограничениям, выставленным этими параметрами, чтобы можно было принять решение - разрешён этот запрос или нет.
Если у вас есть один запрос, который вызывается раз в месяц, и множество запросов, которые отрабатывают каждую минуту, то проверяться будут все - собственно, поэтому эффективность в данном месте и критична.

Так себе аргументация.

Ну Вам виднее, конечно, не буду больше спорить. Только направлю Ваши усилия по более рациональному пути: если хотите реальных изменений - пишите свои "хотелки" в виде enhancement request-ов на support.zabbix.com, там для этого существует специальный проект "ZBXNEXT"; и уже там дискутируйте с разработчиками и аргументируйте так, чтобы убедить в своей правоте их. Прямо скажу - мне удавалось далеко не всегда.
Только нужно там один раз зарегистрироваться (но это несложно), а писать - по-английски.

[Alex_UUU]

Ок. Тогда такая ситуация:
Запретили систем рун, или ограничили конкретными скриптами, которые закинули на сервер.
Появляется новая задача. Сожно, конечно закинуть в ЮзерПараметр и т.д. Перезагрузить агента
А если доступа нет?
С систем рун приходилось и файлы на сервер закидывать, не говоря уже о перезагрузке агета.

[teddy]

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

Вот именно поэтому она и небезопасна.
Ибо неведомо что за файл можно будет закинуть на сервер и запустить... возможны любые в т.ч вредоносные действия со стороны администратора заббикс сервера или кого, то кто сможет вклинится в протокол обмена.
Безопасность исходит из невозможности навредить а тут такая возможность как бы зашито. И передано на сторону администратора заббикс сервера, который для удаленных машин еще "один почти бог", кроме домейн админа если мы говорим про win машины, но за Domain Administrator следят все кто не лень, ибо написано в каждой книжке. а тут кто не знает - то и не догадается.

в случае Linux машин тут уже зависит от прав пользователя, под которым крутится агент. но если вы, как пишете выше, хотите иметь широкие возможности для system.run - то наверняка или root, или возможность sudo. А это опять таки возможность неконтролируемых действий..

Что в сумме явно требует особого внимания. т.е небезопасно само по себе.

[Alex_UUU]

Ну если ТУЗ zabbix дали полные рутовые права, то да, многое можно.