☰

Доступ Grep к maillog для не-root

tag-icon • tag-icon centos permissions sudo
Доступ Grep к maillog для не-root

Я хотел бы предоставить определенному (обычному) пользователю grepдоступ к моим почтовым журналам ( /var/log/maillog*).

Я не готов менять разрешения на доступ к журналам, поскольку они должны оставаться доступными rootтолько для чтения, поэтому я думаю, что предпочтительным решением будет использование sudoers.

Кроме того: я хочу предоставить как можно меньше других разрешений, в идеале у пользователя должен быть доступ только к почтовому журналу (и ротируемым файлам).

Например:

username ALL= NOPASSWD: /bin/grep

Позволяет этому пользователю работать практически grepс любым файлом в системе, чего я хотел бы избежать.

Какое решение здесь является наилучшим?
К вашему сведению: оно не обязательно должно быть grepкак таковым: пользователю нужен только доступ на чтение почтовых журналов, и, вероятно, он будет использовать его только grepдля доступа к ним.

решение1

Вы можете использовать ACL для файла(ов), чтобы предоставить пользователю разрешение на чтение.

setfacl -m user:grepuser:r /var/log/maillog*

Это преимущество позволяет пользователю использовать любой инструмент по своему желанию.

Это также безопасно для logrotate для maillog*

решение2

Если вы не знаете, какие конкретные строки будут искать пользователи и какие конкретные файлы они будут проверять, sudoэто не лучшее решение. Если вы создадите правило вроде этого:

blizz ALL=root NOPASSWD: /bin/grep * /var/log/maillog*

Пользователь сможет выполнять такие команды:

grep root /etc/shadow /var/log/maillog
grep = /root/my.cnf /var/log/maillog

Они смогут прочитать любой файл в системе. Вы можете найти больше информации об этой проблеме здесь:

http://blog.csnc.ch/2012/10/dangerous-sudoers-entries-part-4-wildcards/

Если вы знаете, какие строки и файлы будет проверять пользователь, вы можете определить отдельные правила для каждого сценария. Например:

Cmnd_Alias  MAILLOGA = /bin/grep 'Connection refused' /var/log/maillog
Cmnd_Alias  MAILLOGB = /bin/grep 'Connection refused' /var/log/maillog.1
Cmnd_Alias  MAILLOGC = /bin/grep 'imap-login' /var/log/maillog
Cmnd_Alias  MAILLOGD = /bin/grep 'imap-login' /var/log/maillog.1
blizz ALL=root NOPASSWD: MAILLOGA, MAILLOGB, MAILLOGC, MAILLOGD

Однако это может оказаться громоздким и привести к слишком большой конфигурации sudo.

В качестве альтернативы, вместо того, grepчтобы предоставить им доступ к файлам через moreкоманду, они могли бы выполнять поиск файлов в интерактивном режиме:

Cmnd_Alias  MAILLOG = /bin/more /var/log/mailllog
Cmnd_Alias  MAILLOG1 = /bin/more /var/log/mailllog.1
Cmnd_Alias  MAILLOG2 = /bin/more /var/log/mailllog.2
Cmnd_Alias  MAILLOG3 = /bin/more /var/log/mailllog.3
blizz ALL=root NOPASSWD: MAILLOGA, MAILLOGB, MAILLOGC, MAILLOGD

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

Примечание:Непредоставить sudo доступ к lessкоманде. Пользователь может выйти из процесса, например, запустив , !/bin/bashон lessполучит root-доступ к системе.

Другой вариант — установить для них правила доступа к catфайлам, чтобы они могли перенаправлять их grepпо своему усмотрению. Например:

sudo cat /var/log/maillog | grep "anything can go here"

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

groupadd logcheck
chgrp logcheck /var/log/maillog*
chmod g+r /var/log/maillog*
useradd -G logcheck blizz

Затем они могут использовать любой инструмент для анализа файлов (например grep, zgrep, less, more, view, и т. д.).

решение3

Это должно работать так, как и ожидалось.sudoersфайл:

%users  ALL= /bin/cat /var/log/mail.log
%users  ALL= /bin/cat /var/log/mail.err

(пути к журналам из Ubuntu, при необходимости измените)

Использование универсального инструмента, предназначенного только для вывода данных, напримеркотпросто и безопасно. Вам не придется разрешать и ограничивать определенные опции, как сгрэппрямо в sudoers. Это также позволит фильтровать логи с любымgrep-или-нетинструмент, т.е.awk,сед.

Не уверен каксудонастроен в CentOS, но если он запрашивает парользвонокпользователь (не изцельпользователь), я бы избегал использованияНЕТ ПАРОЛЬ. Это может быть преимуществом безопасности, если какая-либо враждебная сторона получит доступ к учетной записи пользователя, не зная его пароля.

Связанный контент