Sudoers за один день в неделю?

10

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

Сейчас у нас 53 пользователя, которые занимаются этим, и это кошмар аудита. Мне интересно, можно ли разрешить доступ пользователям только в определенные дни недели.

Например, можно ли разрешить пользователю «Джо» входить в систему ТОЛЬКО по вторникам и четвергам, а «Джейн» - только по воскресеньям? Может etc/sudoersбыть настроен, чтобы позволить это?

Есть ли лучший способ вместо использования sudoers?

Крис
источник
10
Я бы порекомендовал НЕ читать страницу руководства. См. Xkcd # 1343
user60684
3
Нет, я говорю ему не читать руководство, потому что невозможно прочитать ИМХО. ОП, вероятно, найдет ответ на странице руководства, если его будет легче читать.
user60684
10
Вы можете сделать это, но имейте в виду, что пользователи могут просто вернуть себе постоянный доступ к sudo в любой день, когда у них есть root.
Ник Маттео
2
@ Mark0978, если бы вы знали название компании, вы, вероятно, умрете, смеясь над головой. Это позор, что это разрешено ... на рабочем сервере.
Крис
3
Это кажется глупым. Это просто означает, что Биллу придется ждать своего утреннего интервала времени в среду rm -rf /.
Майкл Хэмптон

Ответы:

21

sudo выполняет аутентификацию через PAM, как и почти все остальное на Linux.

Таким образом, вы должны быть в состоянии использовать pam_time.soдля этого.

По крайней мере, по умолчанию в Debian этот модуль не включен. Вам нужно добавить строку, которая выглядит следующим образом:

account    requisite  pam_time.so

либо /etc/pam.d/sudoвключить только для sudo, либо /etc/pam.d/common-account(после блока pam-auth-update) включить для всех программ в системе.

Затем отредактируйте, /etc/security/time.confчтобы установить свои ограничения. Название сервиса должно быть sudo. Например, чтобы разрешить Фреду использовать sudoтолько с 15:00 до 17:00 в пятницу:

sudo;*;fred;Fr1500-1700

(ПРИМЕЧАНИЕ: я не проверял это.)

редактировать: для ясности, я согласен с другим ответом и различными комментариями, у вас слишком много людей, выполняющих слишком много команд от имени пользователя root, и вам действительно нужно это исправить. И, конечно, если они могут стать root, они могут редактировать конфигурацию pam ...

derobert
источник
PAM кажется сложным для реализации, но также обеспечивает более жесткий контроль над тем, кто что делает и когда. Принят и проголосовал. Спасибо.
Крис
2
Я не думаю, что ободрять его - это правильный ответ, IMAO правильный ответ на этот вопрос: «Беги за холмы !!!! 1! 1 !! 1! 1»
o0 '.
Это на самом деле работает? Я могу управлять различными механизмами входа в систему, такими как «login», «ssh», «gdm», «su», используя pam_time.so, но это не работает для sudo. Я хочу не допустить, чтобы кто-либо получал root с помощью любого обычного механизма в нерабочее время. (Я понимаю, что это не пуленепробиваемый, кто-то может заранее приготовить оболочку setuid или бэкдор, но я не ожидаю, что это произойдет в этой ситуации.)
Сэм Уоткинс
20

Я бы задал вопрос, зачем 53 пользователям нужен sudo для выполнения своей повседневной работы - для большинства пользователей (даже разработчиков) sudo должно быть редким исключением, а не такой обычной вещью, когда кто-то случайно запускает sudo rm -rf *команду.

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

Даже если вы можете ограничить доступ пользователей sudo одним днем ​​в неделю, это все равно 53 человека с доступом sudo за неделю, так что это не поможет решить вашу основную проблему.

В связи с этим я бы спросил, нужно ли вообще многим пользователям доступ к производственному серверу - можете ли вы отправлять журналы или любые другие данные / файлы, которые им нужны, на непроизводственную машину?

Джонни
источник
Или вы можете опубликовать какой-нибудь доступ к файлам журналов, которые им могут понадобиться, - это установка типа chroot в тюрьму sftp.
Боевой кодер
@ Джонни, большая часть работы, выполняемой на этом хосте, заключается в создании / редактировании и запуске сценариев оболочки. Пользователи не должны иметь права vi/cp/mv/rm. Только cdи more. Ничего больше.
Крис
@Johnny Если я устанавливаю ACL для каталога, файлы в этом каталоге наследуют атрибуты ACL по умолчанию?
Крис
@Chris Да, если вы устанавливаете ACL по умолчанию для каталога.
Майкл Хэмптон
Это должен быть комментарий, а не ответ. Независимо от того, является ли сценарий ОП разумным, у других людей есть аналогичная потребность заблокировать «sudo» для некоторых пользователей в определенные моменты времени.
Сэм Уоткинс
7

Самый простой способ - использовать suders.d (через inludedir) для вашей конфигурации. Тогда вы могли бы иметь задания cron, которые могли бы помещать правила для каждого пользователя в этот каталог в любое время.

Директива #includedir может использоваться в / etc / sudoers для создания каталога sudo.d, в который вы можете добавить правила sudoers как часть ваших правил. Например, с учетом:

#includedir /etc/sudoers.d

sudo будет читать каждый файл в /etc/sudoers.d, пропуская имена файлов, заканчивающиеся на '~' или содержащие '.' символ, чтобы избежать проблем с менеджером пакетов или редактором временных / резервных файлов. Файлы анализируются в отсортированном лексическом порядке. То есть /etc/sudoers.d/01_first будет проанализирован до /etc/sudoers.d/10_second. Помните, что поскольку сортировка является лексической, а не числовой, /etc/sudoers.d/1_whoops будет загружен после /etc/sudoers.d/10_second. Использование одинакового количества лидирующих нулей в именах файлов может быть использовано, чтобы избежать таких проблем.

Обратите внимание, что в отличие от файлов, включаемых через #include, visudo не будет редактировать файлы в каталоге #includedir, если один из них не содержит синтаксическую ошибку. Все еще возможно запустить visudo с флагом ‑f для непосредственного редактирования файлов.

/etc/sudoers.d/joe будет присутствовать, когда вы хотите, чтобы у joe был доступ, и вы могли бы просто удалить файл, чтобы лишить его доступа.

jamespfinn
источник
1
У меня была проблема с моими пользовательскими файлами sudoers: 'sudoers.user1' и т. Д. Вы отмечаете "~" и "." персонажи решили мою проблему. Я так рад, что вы прочитали руководство! Спасибо.
Хан
0

Вы можете добавить crontab, чтобы поместить пользователей в группу sudo, а затем второй crontab, чтобы убрать этого пользователя.

PolarisUser
источник