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

10

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

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

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

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

permissions security sudo

— Крис
источник

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
источник