Мое приложение требует доступа для чтения /var/log/messages, который принадлежит пользователю и группе root. Какой минимальный уровень воздействия требуется для того, /var/log/messagesчтобы мое приложение могло его прочитать?
В настоящее время мой план состоит в том, чтобы изменить владельца группы /var/log/messagesна новую группу и добавить в нее пользователя root и пользователя моего приложения, но это также даст привилегии записи приложения /var/log/messages.
ОС: Centos 5.5
Ответы:
Нет необходимости добавлять root в группу, так как в любом случае он будет иметь доступ через привилегированный пользователь, просто прочитайте группу для любой группы, которую вы решите. Не забудьте вносить изменения также с помощью logrotate, иначе групповые изменения будут стираться каждую ночь.
Просто чтобы немного расширить приведенные выше ответы, это реальный пример использования. Я запускаю приложение Splunk для анализа журналов предприятия на коробке Redhat. Он работает под пользователем Spunk и группой Spunk. Это предотвращает доступ спленков к журналам в / var / log, так как они доступны только пользователю root (или администратору sudo)
Чтобы разрешить доступ только для чтения только для splunk, я использовал некоторые ACL и модифицировал logrotate, чтобы сохранить его.
Вы можете вручную установить ACL с помощью
sudo setfacl -m g:splunk:rx /var/log/messages
Это не будет сохраняться, так как logrotate не будет повторно применять настройку ACL, поэтому для более постоянного решения я добавил правило logrotate для сброса ACL. Я добавил файл ..
/etc/logrotate.d/Splunk_ACLs
с
{
postrotate
/usr/bin/setfacl -m g:splunk:rx /var/log/cron
/usr/bin/setfacl -m g:splunk:rx /var/log/maillog
/usr/bin/setfacl -m g:splunk:rx /var/log/messages
/usr/bin/setfacl -m g:splunk:rx /var/log/secure
/usr/bin/setfacl -m g:splunk:rx /var/log/spooler
endscript
}
Проверьте статус ACL файла с
$ getfacl /var/log/messages
Для получения дополнительной информации о ACL смотрите https://help.ubuntu.com/community/FilePermissionsACLs http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/
/etc/logrotate.d/Splunk_ACLsкоторый вы там разместили? Вам на самом деле не нужно указывать какие-либо пути для logrotate для обработки постротационного бита?
Ваш план приемлем, и в «традиционной» схеме разрешений Unix это лучший путь.
Другой вариант - заставить системный журнал переадресовывать сообщения, представляющие интерес, в другой файл (что исключает предоставление пользователю приложения доступа ко всему, что может быть чувствительным /var/log/messages).
Если вы не чувствуете себя связанными традиционной схемой разрешений «Пользователь / Группа / Другое», вы также можете использовать списки управления доступом POSIX (другие, возможно, лучшие инструкции / сведения, доступные через Google), чтобы предоставить вашему приложению доступ только для чтения к /var/log/messages- это немного более детально и не рискует случайно поместить кого-то еще в группу приложения и дать им доступ к вещам, которые они не должны видеть.
Да, я использовал setfaclэто для предоставления доступа к mail.logфайлу для клиента, но вам также не нужно будет вставлять команду в logrotate.confфайл для переустановки ACL после ротации журналов, например:
postrotate
/usr/bin/setfacl -m o::r /var/log/mail.log
endscript
Заметьте, я только что настроил это и не проверял, но, хотя он будет публиковать здесь, не может понять, почему это не сработает, кто-то исправит меня, если я ошибаюсь.