☰

Индивидуальная политика

tag-icon • tag-icon selinux logstash
Индивидуальная политика

Я хочу запустить logstash как root, чтобы разрешить ему читать все журналы (предоставлять ему доступ ко всем журналам очень утомительно). Однако я не хочу, чтобы он буйствовал на моем сервере, я думал о том, чтобы ограничить его с помощью SELinux.
Я вижу следующие варианты:

  • Создать совершенно новую метку для logstash. Это также означает создание меток для файлов конфигурации logstash, исполняемых файлов и библиотек logstash и т. д.
  • Запустить logstash, используя метку, предназначенную для другого процесса. Я положил глаз на нее, clogd_tтак как она есть logв ее имени, и я не смог найти никаких подозрительных разрешений на запись, используяsudo sesearch --allow -s clogd_t | grep clogd_t | less -p write
  • Откажитесь и запустите его как неограниченный корневой процесс.

Нормально ли это?

Если это имеет значение, я использую CentOS 6.7.

решение1

Я бы предпочел создать индивидуальную политику, потому что это понятнее и позволяет вам контролировать происходящее.

Индивидуальная политика

Насколько я понимаю, это демон на основе Java, который вы будете запускать, поэтому, вероятно, разумно будет запустить его как system_u:system_r:logstash_t. Затем вам нужно будет предоставить (только чтение?) доступ ко всем файлам журналов в домене logstash_t и, наконец, предоставить любые дополнительные разрешения, которые могут потребоваться logstash для запуска.

Используя интерфейсы refpolicy, мы получаем что-то вроде:

policy_module(logstash, 1.0)

# define the entry point and the domain
type logstash_exec_t
init_daemon_domain(logstash_t, logstash_exec_t)

Затем демон logstash должен иметь возможность читать файлы журналов:

logging_search_all_logs(logstash_t)
logging_getattr_all_logs(logstash_t)
logging_read_all_logs(logstash_t)

Этого должно быть достаточно, затем вам нужно будет добавить остальное.

Повторно использованная политика

Что касается второго пункта, я не уверен, почему вы не получаете никакого разрешения на запись, о котором сообщает sesearch, но если вы посмотрите на источники:

# clogd.te
storage_raw_read_fixed_disk(clogd_t)
storage_raw_write_fixed_disk(clogd_t)

# storage.te 
########################################
## <summary>
##      Allow the caller to directly write to a fixed disk.
##      This is extremely dangerous as it can bypass the
##      SELinux protections for filesystem objects, and
##      should only be used by trusted domains.
## </summary>
## <param name="domain">
##      <summary>
##      Domain allowed access.
##      </summary>
## </param>
#
interface(`storage_raw_write_fixed_disk',`
# and the rest of the stuff here...

Не совсем то, что можно было бы хотеть от инструмента мониторинга журналов. Вы можете найти что-то подходящее для использования со вторым решением, просто убедитесь, что вы не получаете дополнительных ненужных разрешений, так как это сводит на нет весь смысл запуска процесса внутри selinux.

Надеюсь, поможет.

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