Intereting Posts
Использовать шрифт PSF в эмуляторе терминала X11 Сделать пользователя администратором группы без редактирования вручную / etc / gshadow Команда для работы со всеми файлами в папке и вывода результата в один файл утечка памяти awk? Как узнать, какие приложения установлены в Linux? Удалить последнюю строку из файла Настройка точки доступа OpenWRT Archer C7v2 Как показать полное имя дня с помощью команды, например, 16 июля 1991 г. Копы не смогли развернуть elb для входного controllerа stat на зашифрованном томе в osx занимает много времени Как преобразовать этот формат временной метки в другой формат в Perl? Список дерева каталогов, скрипт не работает в csh? как мы можем использовать несколько переменных в одиночном для цикла в сценарии оболочки? Сетевой туннель – домашний сервер через выделенный IP-адрес переключения Как удалить апостроф (') из нескольких столбцов файла .CSV?

Разрешить пользователям запускать только определенные двоичные файлы с правами root / привилегиями

Я хотел бы, чтобы конкретный пользователь мог использовать только sudo /sbin/iptables .

У меня есть скрипт bash, который настраивает iptables. Проблема в том, что настройка /sbin/iptables качестве sudoable недостаточна – сам скрипт также должен быть правдоподобным.

Проблема в том, что этот файл может быть отредактирован пользователем (он может изменять конфигурации там), предоставляя ему возможность запускать любую команду как root.

Каков правильный подход к этой проблеме?

Я вижу два метода:

  1. Разрешить пользователю использовать /sbin/iptables через sudo без ограничений (что-то опасно, это означает, что вы как-то доверяете пользователю) и запускайте скрипт с разрешениями пользователя. Сценарий будет вызывать sudo каждый раз /sbin/iptables . Это предполагает, что выполнение скрипта будет быстрым, так как в некоторых случаях потребуется ввести пароль в определенные интервалы времени¹.

    • Преимущество: вам не нужно доверять скрипту.
    • Недостаток: как уже упоминалось, использование пользователем /sbin/iptables без ограничений является чем-то опасным.
  2. Разрешить пользователю вызывать только скрипт через sudo .

    • Преимущество: использование /sbin/iptables ограничено скриптом.
    • Недостаток: сценарий должен быть безупречным.

О проблеме, о которой вы упомянули: если скрипт принадлежит, скажем, root и имеет обычные разрешения: rwxr-xr-x , другие пользователи не могут его модифицировать, они могут выполнять его (в конечном итоге через sudo чтобы получить больше привилегий).

С решением 2, а в случае сценариев оболочки (по сравнению с более надежными двоичными файлами / программами), будьте осторожны с переменными окружения и несколькими внешними факторами, которые могут изменить выполнение вашего скрипта. Убедитесь, что ваша конфигурация sudo правильно сбрасывает определение каждой потенциально опасной переменной.


1. На самом деле, sudo можно настроить с помощью NOPASSWD если это необходимо.

Из Википедии:

setuid и setgid (сокращение для «установить идентификатор пользователя при выполнении» и «установить идентификатор группы при выполнении» соответственно) [1] – это флаги прав доступа Unix, которые позволяют пользователям запускать исполняемый файл с разрешениями владельца или группы исполняемого файла. Они часто используются, чтобы позволить пользователям в компьютерной системе запускать программы с временно повышенными привилегиями для выполнения конкретной задачи. Хотя предполагаемые привилегии идентификатора пользователя или группы идентификаторов не всегда повышаются, как минимум они являются конкретными.

Попробуйте что-то вроде этого

 stefan@linux-ulsk:/usr/bin> zypper up Root privileges are required for updating packages. linux-ulsk:~ # whereis zypper zypper: /usr/bin/zypper /usr/bin/X11/zypper /usr/include/zypper /usr/share/zypper /usr/share/man/man8/zypper.8.gz linux-ulsk:~ # chmod u+s /usr/bin/zypper linux-ulsk:~ # exit stefan@linux-ulsk:/usr/bin> zypper up Retrieving repository ... 

Я мог начать zypper, не будучи корнем, чего раньше не мог.

Будьте осторожны с setuid и setgid! Некоторые цитаты из книги:

Никогда не давайте разрешение на использование скриптов shell. Известно несколько методов их подвергания.

Вы можете попробовать изменить владельца группы файла и добавить своего пользователя в эту группу. Затем вы можете chmod файл, чтобы назначить групповые разрешения, которые позволят вам делать то, что вам нужно.

Это изменчивое решение, но это сработает.

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

Если они могут выполнить, но не записать файл, тогда вы можете добавить эту команду в свой список sudo.